Введение в модель данных в Кассандре
Apache Cassandra стала одной из самых мощных баз данных NoSQL. Это правильный выбор, когда вам нужна высокая доступность и масштабируемость без ущерба для производительности, особенно для приложений, которые не могут позволить себе потерять данные. В этой теме мы собираемся узнать о модели данных в Кассандре.
Быстрый факт, инженеры Cassandra являются одними из самых высокооплачиваемых технических специалистов сегодня. Такие компании, как Netflix, Instagram и Apple, используют Cassandra для обеспечения индивидуального обслуживания клиентов. Чтобы получить правильную производительность, вам необходимо тщательно разработать схему, характерную для бизнес-задачи. В этой статье мы рассмотрим модель данных Cassandra, которая значительно отличается от того, что мы видим в RDBMS.
Правила модели данных Кассандры
Проще говоря, модель данных - это логическая структура базы данных. Он описывает, как данные хранятся и доступны, а также отношения между различными типами данных.
Выбор правильной модели данных может быть самой сложной частью использования базы данных NoSQL, такой как Cassandra. Как я упоминал ранее, моделирование данных в Cassandra отличается от того, что мы видим в RDBMS.
Ключ раздела и ключ кластеризации - это термины, которые должен знать каждый, кто имеет дело с Кассандрой. Прежде чем мы углубимся в основные правила моделирования данных в Cassandra, давайте быстро рассмотрим, что означают эти термины,
раздел
Cassandra - это распределенная база данных, в которой данные распределяются и хранятся в разных узлах кластера. Данные разделяются с использованием ключа разделения, который может быть одним или несколькими полями данных. Этот ключ раздела используется для создания механизма хеширования для равномерного распределения данных по всем узлам.
кластер
Кластер - это набор узлов, представляющих одну логическую базу данных. Ключ кластеризации состоит из одного или нескольких полей, которые используются для группировки данных в разделе.
В этой таблице ресторанов данные будут разделены с использованием country_code, state_name и city_name, а внутри этого раздела данные будут кластеризованы и отсортированы на основе открывающиеся данные и restaurant_name.
Теперь давайте рассмотрим два правила моделирования данных, которые следует учитывать.
- Данные распределены равномерно по всему кластеру
- Читайте как можно меньше разделов
Давайте посмотрим на то, что эти правила пытаются передать
- Мы знаем, что кластер является правильным? Кластер состоит из нескольких узлов. Мы хотим распределить данные между этими узлами так, чтобы каждый узел имел примерно одинаковый объем данных. Как мы знаем, данные разбиваются на разные узлы с помощью хэша ключа разделения (который является первым ключом первичного ключа), поэтому вкратце: «Вы должны выбрать хороший первичный ключ».
- Каждый раздел находится на отдельном узле, поэтому при получении данных вы хотите убедиться, что данные извлекаются из как можно меньшего числа разделов. Если вашему запросу требуются данные из разных разделов, для отдельных узлов будет введена команда, чтобы получить эти данные, что приведет к накладным расходам и задержке.
Ключом к эффективной модели данных будет баланс между этими двумя правилами.
Обработка отношений в Кассандре
Следует иметь в виду, что моделирование данных в Cassandra выполняется с использованием подхода, основанного на запросах, в отличие от RDBMS, где вы сначала идентифицируете сущности, создаете таблицы, а затем формируете запросы, используя JOINS для извлечения данных.
Проще говоря, мы не моделируем отношения или объекты, мы моделируем запросы.
1. Отношение один к одному
Например, в университете студент может зарегистрироваться только на один семинар. Это отношения один на один. Сохраняя правило № 1, мы думаем о запросах, которые мы хотим. Я хочу найти семинар, который посещает студент. В этом случае мы составим всего одну таблицу. Таблица должна содержать данные об ученике и семинаре.
2. Отношение один ко многим
В том же контексте, что, если я хотел бы найти всех студентов, посещающих семинар. Вместо того, чтобы использовать одну и ту же таблицу и выполнять итерацию по каждой строке, чтобы получить имя студента для этого конкретного семинара, я могу создать другую таблицу, которая разбивает данные по имени семинара. Поэтому, когда я выполняю запрос, он попадает только на один узел, а не на все узлы, чтобы получить название семинара.
3. Отношение ко многим ко многим
Теперь, давайте рассмотрим, студент может посещать много семинаров, и семинар может посещать много студентов. Здесь у нас много-много отношений. В этом случае вы можете использовать две вышеупомянутые таблицы для выполнения запросов без дополнительных затрат на создание сложных запросов с использованием объединений, что вы обычно делаете в RDBMS.
Важность Кассандры
С быстрым расширением цифровых данных становится все более важным иметь хорошо масштабируемую и отказоустойчивую базу данных. Позвольте мне перечислить несколько моментов, почему вы должны использовать Кассандру
- Освещение операций быстрого чтения: мы обсудили, как правильное моделирование ваших данных может оптимизировать операции чтения в широком масштабе.
- Отказоустойчивость: данные реплицируются между узлами, поэтому даже если один узел выходит из строя, ваши данные в безопасности.
- Пользовательская настройка: вы можете настроить Cassandra для работы в соответствии с вашей рабочей нагрузкой. Если вы пишете много данных, например, ведение журнала, вы можете настроить их для работы с системами с интенсивной записью. Есть несколько других доступных вариантов настройки.
- Работа с большими объемами данных: в зависимости от размера кластера Cassandra может работать с огромными объемами данных.
Как моделировать данные в Кассандре?
Хорошее моделирование данных следует за этими шагами
- Концептуализация запросов, требуемых вашим приложением
- Создание таблиц для удовлетворения этих запросов
Прежде чем применять эти правила, необходимо помнить следующее: «Мы сосредоточены на оптимизации наших операций чтения, даже если это требует дублирования данных». У нас может быть много таблиц, которые могут содержать почти одинаковые данные.
Теперь рассмотрим, нам нужна база данных, в которой хранится информация о ресторанах. Давайте наложим ограничение на то, что названия ресторанов должны быть уникальными.
Приведенную ниже таблицу можно использовать, когда мы хотим искать по названию ресторана:
Теперь, если мы хотим найти рестораны для определенного местоположения, мы напишем запрос, который перебирает все строки и извлекает названия ресторанов.
Вместо этого, имея в виду правило № 2, мы можем легко создать еще одну таблицу, которая будет обслуживать наши потребности.
Теперь наши данные будут разделены таким образом, чтобы у узла в кластере были рестораны для определенного местоположения. Это оптимизирует наши запросы на чтение, так как поиск запросов будет происходить только на одном узле с гораздо меньшими строками, чем в первой таблице, которую мы создали.
Что, если мы хотим искать рестораны в определенном городе, мы можем создать другую таблицу, а не перебирать все строки в одном разделе таблицы выше.
Вывод
В этой статье я рассмотрел несколько рекомендаций, которым вы можете следовать, как подходить к моделированию данных в Cassandra. Если вы понимаете эти концепции и можете эффективно распознавать тип запросов, в которых нуждается ваше приложение, вы можете разработать отличную модель данных, чтобы добиться высокой производительности вашей базы данных.
Рекомендуемые статьи
Это руководство по модели данных в Кассандре. Здесь мы обсудим, как моделировать наши данные в Cassandra вместе с правилами и Важностью Моделей данных Cassandra. Вы также можете просмотреть наши другие предлагаемые статьи, чтобы узнать больше -
- Что такое моделирование данных?
- Модели данных в СУБД
- Интервью по моделированию данных
- Cassandra Data Modeling