Cassandra Модель даних із простим прикладом бази даних

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

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

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

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

Збільште кількість записів

In Cassandra, пише дуже дешево. Cassandra оптимізовано для високої продуктивності запису. Тому намагайтеся максимізувати кількість записів для кращої продуктивності читання та доступності даних. Існує компроміс між записом і читанням даних. Отже, оптимізуйте продуктивність читання даних, збільшивши кількість записів даних.

Збільште дублювання даних

Денормалізація даних і дублювання даних є дефакто Cassandra. Дисковий простір не дорожчий, ніж пам'ять, обробка ЦП і операції вводу-виводу. як Cassandra це розподілена база даних, тому дублювання даних забезпечує миттєву доступність даних і відсутність єдиної точки відмови.

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

Ви повинні мати такі цілі під час моделювання даних Cassandra:

Рівномірно розподіліть дані навколо Cluster

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

Мінімізуйте кількість розділів, які читаються під час запиту даних

Розділ — це група записів з однаковим ключем розділу. Коли надсилається запит на читання, він збирає дані з різних вузлів із різних розділів.

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

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

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

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

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

Ось таблиця 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. У цій таблиці щороку буде створюватися новий розділ. Усі пісні року будуть на одному вузлі. Цей первинний ключ буде дуже корисним для даних.

Завдяки цій моделі даних наш пошук даних буде швидким.

Моделюйте свої дані Cassandra

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

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

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

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

• з'єднання
• Групувати за
• Фільтрування по якому стовпцю тощо.

Створіть таблицю відповідно до ваших запитів

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

Керування стосунками один на один Cassandra

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

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

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

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

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

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

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

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

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

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

Обробка зв’язків «багато до багатьох». Cassandra

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

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

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

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

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

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 та Cassandra Моделювання даних

СУБД	Cassandra
Зберігає дані в нормалізованому вигляді	Зберігає дані в денормализованій формі
Застарілі СУБД; структуровані дані	Широкий рядний магазин, Dynamic; структуровані та неструктуровані дані

Підсумки

• Моделювання даних в Cassandra відрізняється від інших Бази даних RDBMS.
• Cassandra моделювання даних має деякі правила. Для якісного моделювання даних необхідно дотримуватися цих правил. Окрім цих правил, ми побачили три різні випадки моделювання даних і способи їх вирішення.
• Відношення один до одного означає, що дві таблиці відповідають один до одного.
• Відношення один до багатьох означає наявність відповідності один до багатьох між двома таблицями.
• Відношення «багато до багатьох» означає наявність відповідності «багато до багатьох» між двома таблицями.