Модель даних Кассандри на простому прикладі

Хоча мова запитів Кассандри нагадує мову SQL, їх методи моделювання даних абсолютно різні.

У Кассандрі погана модель даних може погіршити продуктивність, особливо коли користувачі намагаються впровадити концепції СУБД на Кассандрі. Краще мати на увазі кілька правил, докладно описаних нижче.

У цьому підручнику ви дізнаєтесь-

Правила моделі даних Кассандри
Змоделюйте свої дані в Кассандрі
Управління відносинами один до одного
Обробка одних із багатьма стосунками
Робота з стосунками багатьох до багатьох

Правила моделі даних Кассандри

У Кассандрі пише не дорого. Кассандра не підтримує об’єднання, групування, речення АБО, агрегації тощо. Отже, ви повинні зберігати свої дані таким чином, щоб вони мали бути повністю доступними. Тож ці правила потрібно пам’ятати під час моделювання даних у Кассандрі.

Максимізуйте кількість записів
У Кассандрі пишуть дуже дешево. Кассандра оптимізована для високої продуктивності запису. Тож спробуйте максимізувати свої записи для кращої продуктивності читання та доступності даних. Існує компроміс між записом даних і зчитуванням даних. Отже, оптимізуйте ефективність зчитування даних, збільшивши кількість записів даних.
Максимізуйте копіювання даних
Денормалізація та дублювання даних є дефакто Кассандри. Місце на диску не дорожче за пам'ять, обробку процесора та роботу вводів-виходів. Оскільки Кассандра є розподіленою базою даних, дублювання даних забезпечує миттєву доступність даних і жодної точки відмови.

Цілі моделювання даних

Ви повинні мати наступні цілі під час моделювання даних у Кассандрі.

Розподіліть дані рівномірно по кластеру
Вам потрібна рівна кількість даних на кожному вузлі кластера Кассандри. Дані поширюються на різні вузли на основі розділових ключів, що є першою частиною первинного ключа. Отже, спробуйте вибрати цілі числа як основний ключ для рівномірного розподілу даних по кластеру.
Мінімізуйте кількість розділів, прочитаних під час запиту даних
Розділ - це група записів з однаковим ключем розділу. Коли видається запит на читання, він збирає дані з різних вузлів з різних розділів.

Якщо розділів буде багато, тоді всі ці розділи потрібно відвідати для збору даних запиту.

Це не означає, що не слід створювати розділи. Якщо ваші дані дуже великі, ви не можете зберігати таку величезну кількість даних на одному розділі. Єдиний розділ буде уповільненим.

Тож спробуйте вибрати збалансовану кількість перегородок.

Хороший первинний ключ

Давайте візьмемо приклад і знайдемо, який первинний ключ хороший.

Ось таблиця MusicPlaylist.

Create table MusicPlaylist(SongId int,SongName text,Year int,Singer text,Primary key(SongId, SongName));

У наведеному вище прикладі таблиця MusicPlaylist,

Songid - розділовий ключ, і
SongName - стовпець кластеризації
Дані будуть кластеризовані на основі SongName. За допомогою SongId буде створено лише один розділ. У таблиці MusicPlaylist не буде жодного іншого розділу.

Ця модель даних буде повільно отримувати дані через поганий первинний ключ.

Ось ще одна таблиця MusicPlaylist.

Create table MusicPlaylist(SongId int,SongName text,Year int,Singer text,Primary key((SongId, Year), SongName));

У наведеному вище прикладі таблиця MusicPlaylist,

Songid і Year є розділом, і
SongName - стовпець кластеризації.
Дані будуть кластеризовані на основі SongName. У цій таблиці щороку створюватиметься новий розділ. Усі пісні року будуть на одному вузлі. Цей первинний ключ буде дуже корисним для даних.

Наша модель даних буде швидко отримувати дані.

Змоделюйте свої дані в Кассандрі

Під час моделювання запитів слід пам’ятати про наступні речі.

Визначте, які запити ви хочете підтримувати

Перш за все, визначте, які запити ви хочете.

Наприклад, вам потрібно?

Приєднується
Групувати за
Фільтрування за якою колонкою тощо

Створіть таблицю відповідно до ваших запитів
Створіть таблицю відповідно до ваших запитів. Створіть таблицю, яка задовольнить ваші запити. Спробуйте створити таблицю таким чином, щоб потрібно було прочитати мінімальну кількість розділів.

Управління відносинами один до одного

Відношення один до одного означає, що дві таблиці мають відповідність один до одного. Наприклад, студент може зареєструвати лише один курс, і я хочу шукати у студента те, в якому курсі зареєстрований конкретний студент.

Отже, у цьому випадку схема вашої таблиці повинна охоплювати всі деталі студента, що відповідають цьому конкретному курсу, як-от назва курсу, номер студента, ім’я студента тощо.

Create table Student_Course(Student rollno int primary key,Student_name text,Course_name text,);

Обробка одних із багатьма стосунками

Відношення один до багатьох означає відповідність між багатьма таблицями.

Наприклад, курс може вивчати багато студентів. Я хочу обшукати всіх студентів, які вивчають певний курс.

Отже, запитуючи назву курсу, я отримаю багато імен студентів, які будуть вивчати певний курс.

Create table Student_Course(Student_rollno int,Student_name text,Course_name text,);

Я можу знайти всіх слухачів певного курсу за таким запитом.

Select * from Student_Course where Course_name='Course Name';

Робота з стосунками багатьох до багатьох

Відносини багато-до-багатьох означає наявність відповідності між багатьма таблицями.

Наприклад, курс може вивчати багато студентів, а студент також може вивчати багато курсів.

Я хочу обшукати всіх студентів, які вивчають певний курс. Крім того, я хочу пошукати весь курс, який вивчає конкретний студент.

Тож у цьому випадку я буду мати дві таблиці, тобто розділити проблему на два випадки.

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

Create table Student_Course(Student_rollno int primary key,Student_name text,Course_name text,);

Я можу знайти всі курси конкретного студента за наступним запитом. ->

Select * from Student_Course where student_rollno=rollno;

По-друге, я буду створювати таблицю, за якою ви зможете знайти, скільки студентів вивчає той чи інший курс.

Create table Course_Student(Course_name text primary key,Student_name text,student_rollno int);

Я можу знайти студента за певним курсом за наступним запитом.

Select * from Course_Student where Course_name=CourseName;

Різниця між СУБД та моделюванням даних Кассандри

RDBMS	Кассандра
Зберігає дані у нормалізованому вигляді	Зберігає дані в денормалізованій формі
Спадкові DBM; структуровані дані	Широкорядний магазин, динамічний; структуровані та неструктуровані дані

Резюме

Моделювання даних у Кассандрі відрізняється від інших баз даних СУБД. Моделювання даних Кассандри має деякі правила. Для правильного моделювання даних необхідно дотримуватися цих правил. Окрім цих правил, ми бачили три різні випадки моделювання даних та те, як з ними боротися.