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.

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
);

Оскільки Student_rollno є ключем розділу, пошук за номером списку зчитує рівно один розділ.

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

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

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

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

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

CREATE TABLE Student_Course (
    Course_name text,
    Student_rollno int,
    Student_name text,
    PRIMARY KEY (Course_name, Student_rollno)
);

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

SELECT * FROM Student_Course WHERE Course_name = 'Course Name';

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

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

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

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

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

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

CREATE TABLE Student_Course (
    Student_rollno int,
    Course_name text,
    Student_name text,
    PRIMARY KEY (Student_rollno, Course_name)
);

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

SELECT * FROM Student_Course WHERE Student_rollno = 101;

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

CREATE TABLE Course_Student (
    Course_name text,
    Student_rollno int,
    Student_name text,
    PRIMARY KEY (Course_name, Student_rollno)
);

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

SELECT * FROM Course_Student WHERE Course_name = 'Cassandra';

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

загальний Cassandra Помилки моделювання даних

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

• Необмежені розділи: Вибір ключа розділу, такого як назва країни, поміщає мільйони рядків в один розділ. Додайте часовий інтервал, наприклад (країна, місяць), щоб розділи мали розумний розмір.
• Ключі з дуже низькою кардинальністю: Ключ розділу з лише кількома можливими значеннями, такими як прапорець стану, концентрує весь трафік на кількох вузлах, а решту залишає бездіяльною.
• Використання ALLOW FILTERING для забезпечення роботи запиту: Він сканує кожен розділ і приховує проблему моделювання. Якщо запиту це потрібно, схемі потрібна ще одна таблиця.
• Моделювання сутностей замість запитів: Створення таблиці для студентів та таблиці для курсів, а потім спроба об'єднати їх у застосунку, суперечить меті дизайну.
• Часті видалення та перезаписи: Кожне видалення записує надгробок, який необхідно прочитати та пропустити, доки стиснення не видалить його, що уповільнює читання на гарячих розділах.

Уникнення цього дозволяє узгодити схему з правилами, зазначеними у верхній частині цієї сторінки, та з реляційними контрастами, узагальненими нижче.

Різниця між RDBMS та Cassandra Моделювання даних

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

Поширені запитання