Вступ до моделі даних у Кассандрі
Apache Cassandra став однією з найпотужніших баз даних NoSQL. Це правильний вибір, коли потрібно високу доступність та масштабованість без погіршення продуктивності, особливо для програм, які не можуть дозволити собі втратити дані. У цій темі ми дізнаємось про модель даних в Кассандрі.
Швидкий факт, інженери Cassandra є одними з високооплачуваних професіоналів у галузі техніки. Такі компанії, як Netflix, Instagram та Apple, використовують Cassandra, щоб забезпечити висококваліфікований досвід клієнтів. Щоб отримати правильну продуктивність, потрібно ретельно розробити схему, специфічну для бізнес-проблеми. У цій статті ми розглянемо модель даних Кассандри, яка суттєво відрізняється від тієї, що ми бачимо в RDBMS.
Правила моделі даних Кассандри
Простими словами, Модель даних - це логічна структура бази даних. Він описує спосіб зберігання та доступу до даних та зв’язки між різними типами даних.
Вибір правильної моделі даних може бути найважчою частиною використання бази даних NoSQL, як Cassandra. Як я вже згадував раніше, моделювання даних у Кассандрі відрізняється від того, що ми бачимо в RDBMS.
Роздільний ключ та кластерний ключ - це умови, про які повинен знати кожен, хто має справу з Кассандрою. Перш ніж ми заглибимось у основні правила моделювання даних у Кассандрі, давайте швидко розглянемо, що означають ці терміни,
Перегородка
Кассандра - це розподілена база даних, в якій дані розподіляються та зберігаються в різних вузлах кластеру. Дані розподіляються за допомогою ключа розділу, який може бути одним або декількома полями даних. Цей ключ розділу використовується для створення механізму хешування для рівномірного поширення даних по всіх вузлах.
Скупчення
Кластер - це сукупність вузлів, які представляють єдину логічну базу даних. Ключ кластеризації складається з одного або декількох полів, які використовуються для групування даних разом у розділі.
У цьому ресторані таблиці таблиці дані будуть розподілені за допомогою коду країни, імені держави та імені міста, а в межах цього розділу будуть кластеризовані та відсортовані на основі даних відкриття та імені ресторану.
Тепер давайте розглянемо два правила моделювання даних, які слід пам’ятати.
- Дані розподіляються рівномірно по всьому кластеру
- Читайте з якомога менше розділів
Давайте розглянемо, що ці правила намагаються передати
- Ми знаємо, що таке кластер? Кластер складається з декількох вузлів. Ми хочемо розділити дані серед цих вузлів таким чином, щоб кожен вузол мав приблизно однаковий обсяг даних. Як ми знаємо, дані розподіляються на різні вузли за допомогою хеша ключа розділу (який є першим ключем Первинного ключа), тому коротко - "Ви повинні вибрати хороший Первинний ключ".
- Кожен розділ розміщений на іншому вузлі, тому, коли ви отримуєте дані, ви хочете переконатися, що дані отримуються з якомога меншої кількості розділів. Якщо ваш запит вимагає даних з різних розділів, буде випущена команда для окремих вузлів, щоб отримати вам ці дані, які будуть накладними та призведуть до затримки.
Запорукою ефективної моделі даних буде баланс між цими двома правилами.
Розв’яжіть відносини в Кассандрі
Слід пам’ятати, що моделювання даних у Кассандрі робиться за допомогою керованого запитом підходу, на відміну від RDBMS, де ви спочатку ідентифікуєте об'єкти, створюєте таблиці, а потім формуєте запити, використовуючи JOINS для отримання даних.
Простіше кажучи, ми не моделюємо навколо відносин чи об'єктів, ми моделюємо навколо запитів.
1. Відносини один до одного
Вважайте, що в університеті студент може зареєструватися лише на один семінар. Це стосунки один до одного. Дотримуючись правила №1, ми думаємо про потрібні запити. Я хочу шукати семінар, який відвідує студент. У цьому випадку ми складемо лише одну таблицю. Таблиця повинна містити реквізити студента та дані семінару.
2. Відносини один до багатьох
У тому ж контексті, що робити, якщо я хотів шукати всіх студентів, які відвідують семінар. Замість того, щоб використовувати ту саму таблицю та ітерацію над кожним рядком, щоб отримати ім'я студента для конкретного семінару, я можу зробити іншу таблицю, яка розділяє дані за назвою семінару. Тож коли я видаю запит, він запускає лише один вузол, а не переходить до всіх вузлів, щоб отримати назву семінару.
3. Відносини багатьох до багатьох
Тепер, давайте розглянемо, студент може відвідувати багато семінарів, а в семінарі може взяти участь багато студентів. Тут ми маємо багато-багато стосунків. У цьому випадку ви можете використовувати вищевказані дві таблиці, щоб робити запити, не маючи накладних витрат на складання складних запитів, використовуючи Joins, які ви зазвичай робите в RDBMS.
Важливість Кассандри
Зі швидким розширенням цифрових даних стає важливіше створити високо масштабовану, стійку до відмов базу даних. Дозвольте перерахувати кілька моментів щодо того, чому вам слід використовувати Кассандру
- Освітлення операцій швидкого зчитування: ми обговорили, як правильне моделювання ваших даних дозволяє оптимізувати операції зчитування масовим масштабом.
- Толерантність до відмов: дані реплікуються через вузли, тому навіть якщо один вузол знижується, ваші дані є безпечними.
- Спеціальна настройка: Ви можете налаштувати Cassandra так, щоб вона працювала відповідно до вашої завантаженості. Якщо ви записуєте багато даних, таких як ведення журналів, ви можете налаштувати їх для обробки важких систем. Існує кілька інших варіантів настройки.
- Справа з великими обсягами даних: Виходячи з розміру кластеру, Кассандра може мати справу з величезними обсягами даних.
Як моделювати дані в Кассандрі?
Хороше моделювання даних слідує цим крокам
- Концептуалізуйте запити, необхідні вашою програмою
- Створення таблиць для задоволення цих запитів
Перш ніж застосувати ці правила, потрібно пам’ятати одне: «Ми зосереджуємось на оптимізації наших операцій читання, навіть якщо це вимагає дублювання даних». У нас може бути багато таблиць, які можуть містити майже подібні дані.
Тепер подумайте, що ми хочемо базу даних, яка зберігає інформацію про ресторани. Давайте обмежимось тим, що назви ресторанів повинні бути унікальними.
Таблицю нижче можна використовувати, коли ми хочемо шукати на основі назви ресторану:
Тепер, якщо ми хочемо шукати ресторани для певного місця, ми б написали запит, який повторюється через усі рядки та отримує назви ресторанів.
Натомість, пам’ятаючи правило №2, ми можемо легко створити ще одну таблицю, яка задовольнить наші потреби.
Тепер наші дані будуть розподілені таким чином, що у вузлі кластера будуть ресторани для певного місця. Це оптимізує наші запити для читання, оскільки пошук запитів відбуватиметься лише на одному вузлі зі значно меншими рядками, ніж у першій створеній нами таблиці.
Що, якби ми хотіли шукати ресторани в конкретному місті, ми можемо скласти іншу таблицю, а не повторювати всі рядки в одному розділі вищевказаної таблиці.
Висновок
У цій статті я розповів про декілька найкращих практик, за якими можна дотримуватися способів підходу до моделювання даних у Кассандрі. Якщо ви розумієте ці поняття і зможете ефективно розпізнати тип запитів, які потрібні вашій програмі, ви можете створити чудову модель даних, щоб отримати високу продуктивність зі своєї бази даних.
Рекомендовані статті
Це посібник із Моделі даних у Кассандрі. Тут ми обговорюємо, як моделювати наші дані в Кассандрі разом із правилами та важливістю моделей даних Кассандри. Ви також можете ознайомитися з іншими запропонованими нами статтями, щоб дізнатися більше -
- Що таке моделювання даних?
- Моделі даних у СУБД
- Питання для інтерв'ю щодо моделювання даних
- Моделювання даних Кассандри