Моделирование данных в Cassandra

Автор оригинала: baeldung.

1. Обзор

Cassandra-это база данных NoSQL, которая обеспечивает высокую доступность и горизонтальную масштабируемость без ущерба для производительности.

Чтобы получить максимальную производительность от Cassandra, нам нужно тщательно разработать схему вокруг шаблонов запросов, специфичных для конкретной бизнес-проблемы.

В этой статье мы рассмотрим некоторые ключевые концепции вокруг как подойти к моделированию данных в Cassandra .

Прежде чем продолжить, вы можете ознакомиться с нашей статьей Cassandra with Java, чтобы понять основы и способы подключения к Cassandra с помощью Java.

2. Ключ Раздела

Cassandra-это распределенная база данных, в которой данные секционируются и хранятся на нескольких узлах кластера.

Ключ раздела состоит из одного или нескольких полей данных и используется разделителем для создания маркера с помощью хэширования для равномерного распределения данных по кластеру .

3. Ключ кластеризации

Ключ кластеризации состоит из одного или нескольких полей и помогает кластеризировать или группировать строки с одним и тем же ключом раздела и хранить их в отсортированном порядке.

Предположим, что мы храним данные временных рядов в Cassandra и хотим получить данные в хронологическом порядке. Ключ кластеризации, включающий поля данных временных рядов, будет очень полезен для эффективного извлечения данных в этом случае использования.

Примечание: Комбинация ключа раздела и ключа кластеризации составляет первичный ключ и однозначно идентифицирует любую запись в кластере Cassandra.

4. Рекомендации По Шаблонам Запросов

Прежде чем приступить к моделированию данных в Cassandra, мы должны определить шаблоны запросов и убедиться, что они соответствуют следующим рекомендациям:

1. Каждый запрос должен извлекать данные из одного раздела
2. Мы должны отслеживать, сколько данных хранится в разделе, поскольку у Кассандры есть ограничения на количество столбцов, которые могут храниться в одном разделе
3. Можно денормализовать и дублировать данные для поддержки различных типов шаблонов запросов к одним и тем же данным

Основываясь на приведенных выше рекомендациях, давайте рассмотрим некоторые примеры использования в реальном мире и то, как мы будем моделировать модели данных Cassandra для них.

5. Примеры моделирования Данных В Реальном Мире

5.1. Сообщения в Facebook

Предположим, что мы храним сообщения Facebook разных пользователей в Cassandra. Одним из распространенных шаблонов запросов будет выборка верхних сообщений ” N “, сделанных данным пользователем.

Таким образом, нам нужно хранить все данные для конкретного пользователя в одном разделе в соответствии с приведенными выше рекомендациями.

Кроме того, использование метки времени записи в качестве ключа кластеризации будет полезно для более эффективного извлечения верхних записей ” N “.

Давайте определим схему таблицы Cassandra для этого случая использования:

CREATE TABLE posts_facebook (
  user_id uuid,
  post_id timeuuid, 
  content text,
  PRIMARY KEY (user_id, post_id) )
WITH CLUSTERING ORDER BY (post_id DESC);

Теперь давайте напишем запрос, чтобы найти 20 лучших постов для пользователя Anna :

SELECT content FROM posts_facebook WHERE user_id = "Anna_id" LIMIT 20

5.2. Спортивные залы по всей стране

Предположим, что мы храним сведения о различных партнерских тренажерных залах в разных городах и штатах многих стран, и мы хотели бы получить тренажерные залы для данного города.

Кроме того, предположим, что нам нужно вернуть результаты, отсортировав тренажерные залы по дате их открытия.

Основываясь на приведенных выше рекомендациях, мы должны хранить тренажерные залы, расположенные в данном городе определенного штата и страны, в одном разделе и использовать дату открытия и название тренажерного зала в качестве ключа кластеризации.

Давайте определим схему таблицы Cassandra для этого примера:

CREATE TABLE gyms_by_city (
 country_code text,
 state text,
 city text,
 gym_name text,
 opening_date timestamp,
 PRIMARY KEY (
   (country_code, state_province, city), 
   (opening_date, gym_name)) 
 WITH CLUSTERING ORDER BY (opening_date ASC, gym_name ASC);

Теперь давайте рассмотрим запрос, который выбирает первые десять спортивных залов по дате их открытия в городе Феникс в американском штате Аризона:

SELECT * FROM gyms_by_city
  WHERE country_code = "us" AND state = "Arizona" AND city = "Phoenix"
  LIMIT 10

Далее, давайте рассмотрим запрос, который выбирает десять самых недавно открытых спортивных залов в городе Феникс в американском штате Аризона:

SELECT * FROM gyms_by_city
  WHERE country_code = "us" and state = "Arizona" and city = "Phoenix"
  ORDER BY opening_date DESC 
  LIMIT 10

Примечание: Поскольку порядок сортировки последнего запроса противоположен порядку сортировки, определенному при создании таблицы, запрос будет выполняться медленнее, поскольку Кассандра сначала извлекает данные, а затем сортирует их в памяти.

5.3. Клиенты и продукты электронной коммерции

Допустим, мы запускаем магазин электронной коммерции и храним информацию о Клиенте и Продукте в Cassandra. Давайте рассмотрим некоторые из распространенных шаблонов запросов в этом случае использования:

1. Получить Клиент информация
2. Получить Продукт информация
3. Получить всех Клиентов которым нравится данный Продукт
4. Получить все Продукты данный Клиент лайки

Мы начнем с использования отдельных таблиц для хранения информации о Клиенте и Продукте . Однако нам необходимо ввести достаточное количество денормализации для поддержки 3-го и 4-го запросов, показанных выше.

Для этого мы создадим еще две таблицы – ” Customer_by_Product ” и ” Product_by_Customer “.

Давайте рассмотрим схему таблицы Cassandra для этого примера:

CREATE TABLE Customer (
  cust_id text,
  first_name text, 
  last_name text,
  registered_on timestamp, 
  PRIMARY KEY (cust_id));

CREATE TABLE Product (
  prdt_id text,
  title text,
  PRIMARY KEY (prdt_id));

CREATE TABLE Customer_By_Liked_Product (
  liked_prdt_id text,
  liked_on timestamp,
  title text,
  cust_id text,
  first_name text, 
  last_name text, 
  PRIMARY KEY (prdt_id, liked_on));

CREATE TABLE Product_Liked_By_Customer (
  cust_id text, 
  first_name text,
  last_name text,
  liked_prdt_id text, 
  liked_on timestamp,
  title text,
  PRIMARY KEY (cust_id, liked_on));

Примечание: Для поддержки как запросов, недавно понравившихся продуктов данного клиента, так и клиентов, которым недавно понравился данный продукт, мы использовали столбец ” liked_on ” в качестве ключа кластеризации.

Давайте посмотрим на запрос, чтобы найти десять клиентов, которым в последнее время понравился продукт ” Pepsi “:

SELECT * FROM Customer_By_Liked_Product WHERE title = "Pepsi" LIMIT 10

И давайте посмотрим на запрос, который находит недавно понравившиеся продукты (до десяти) клиентом по имени ” Анна “:

SELECT * FROM Product_Liked_By_Customer 
  WHERE first_name = "Anna" LIMIT 10

6. Неэффективные шаблоны Запросов

Из-за того, как Cassandra хранит данные, некоторые шаблоны запросов совсем не эффективны, в том числе следующие:

• Извлечение данных из нескольких разделов – это потребует, чтобы координатор извлекал данные из нескольких узлов, временно хранил их в куче, а затем агрегировал данные, прежде чем возвращать результаты пользователю
• Запросы на основе соединений – из-за своей распределенной природы Cassandra не поддерживает объединения таблиц в запросах так же, как это делает реляционная база данных, и в результате запросы с | соединениями будут выполняться медленнее, а также могут привести к несогласованности и проблемам доступности

7. Заключение

В этом уроке мы рассмотрели несколько лучших практик, касающихся подхода к моделированию данных в Cassandra.

Понимание основных концепций и заблаговременное определение шаблонов запросов необходимо для разработки правильной модели данных, которая обеспечивает наилучшую производительность кластера Cassandra.