Cassandra Archiтектура та фактор реплікації
Девід Картер
⚡ Розумний підсумок
Cassandra Архітектура розподіляє дані між вузлами-однорангами без єдиної точки відмови, використовуючи gossip для координації та реплікацію для довговічності. Ця сторінка охоплює кожен компонент, як стратегії реплікації, рівні узгодженості, так і внутрішні шляхи запису та читання.
Cassandra призначений для обробки Великий даних. CassandraОсновна особливість — зберігати дані на кількох вузлах без єдиної точки відмови.
Причина такого роду CassandraАрхітектура полягала в тому, що апаратний збій може статися в будь-який момент. Будь-який вузол може не працювати. У разі збою можна використовувати дані, що зберігаються в іншому вузлі. Отже, Cassandra розроблено з його розподіленою архітектурою.
Cassandra зберігає дані на різних вузлах з одноранговою розподіленою архітектурою моди.
Усі вузли обмінюються інформацією один з одним за допомогою Протокол пліток. Плітка — протокол в Cassandra за допомогою яких вузли можуть спілкуватися один з одним.
Компоненти Cassandra Archiтектура
У складі є такі компоненти Cassandra Archiтекстура:
Наведена вище діаграма вкладає компоненти: вузли розташовані всередині центру обробки даних, центри обробки даних розташовані всередині кластера, а журнал комітів, memtable та SSTable знаходяться всередині кожного окремого вузла.
вузол
Вузол - це місце, де зберігаються дані. Це основний компонент Cassandra.
Центр обробки даних
Сукупність вузлів називається центром обробки даних. Багато вузлів класифікуються як центр обробки даних.
Cluster
Кластер — це сукупність багатьох центрів обробки даних.
Журнал фіксації
Кожна операція запису записується в журнал фіксації. Журнал фіксації використовується для відновлення після збою.
Мем-таблиця
Після запису даних у журнал Commit дані записуються в Mem-table. Дані записуються в Mem-таблицю тимчасово.
SSTable
Коли Mem-table досягає певного порогу, дані скидаються у файл SSTable на диску. SSTables є незмінними, тому оновлення записує нову версію, а не редагує стару, а фоновий процес, який називається стисненням, пізніше об'єднує ці версії та видаляє замінені рядки.
Реплікація даних в Cassandra
Оскільки під час обробки даних може виникнути проблема з апаратним забезпеченням або зв’язок може вийти з ладу, потрібне рішення для забезпечення резервної копії, коли проблема виникла. Таким чином, дані копіюються для забезпечення відсутності єдиної точки збою.
Cassandra розміщує копії даних на різних вузлах на основі цих двох факторів.
- Де розмістити наступну репліку, визначає сам Стратегія реплікації.
- Тоді як загальна кількість реплік, розміщених на різних вузлах, визначається Фактор реплікації.
Один коефіцієнт реплікації означає, що існує лише одна копія даних, тоді як три коефіцієнти реплікації означають, що є три копії даних на трьох різних вузлах.
Для забезпечення відсутності єдиної точки відмови, коефіцієнт реплікації повинен бути три.
Існує два типи стратегій реплікації Cassandra.
SimpleStrategy в Cassandra
SimpleStrategy використовується, коли у вас лише один центр обробки даних. SimpleStrategy розміщує першу репліку на вузлі, вибраному секціонером. Після цього репліки, що залишилися, розміщуються за годинниковою стрілкою в кільці Node.
Ось графічне представлення SimpleStrategy:
Мережева топологіяСтратегія в Cassandra
Мережева топологіяСтратегія використовується, якщо у вас більше двох центрів обробки даних. У NetworkTopologyStrategy репліки встановлюються для кожного центру обробки даних окремо. NetworkTopologyStrategy розміщує репліки в кільці за годинниковою стрілкою, доки не досягне першого вузла в іншій стійці. Ця стратегія намагається розмістити репліки на різних стійках в одному центрі обробки даних.
Це пов’язано з тим, що іноді в стійці можуть виникати збої або проблеми. Потім репліки на інших вузлах можуть надавати дані.
Ось графічне представлення стратегії топології мережі:
Коефіцієнт реплікації визначає, скільки копій існує. Скільки з цих копій мають відповідати на заданий запит – це окремий параметр, описаний далі.
Рівні узгодженості в Cassandra
Рівень узгодженості встановлюється для кожного запиту, а не для кожного кластера, що робить Cassandra налаштовуваний. Він визначає, скільки реплік мають підтвердити запис або відповісти на читання, перш ніж координатор відповість клієнту. Низький рівень повертає дані швидше; високий рівень повертає дані, які є більш актуальними.
| рівень | Поведінка | Типове використання |
|---|---|---|
| ONE | Одна репліка повинна відповісти. | Високопродуктивне ведення журналу, де прийнятне випадкове зчитування застарілих даних. |
| QUORUM | Більшість усіх реплік повинні відповісти, що розраховується як (RF / 2) + 1. | Універсальний вибір для збалансованої узгодженості та доступності. |
| МІСЦЕВИЙ_КВОРУМ | Більшість реплік у локальному центрі обробки даних повинні відповідати. | Кластери з кількома центрами обробки даних, оскільки це дозволяє уникнути міжрегіональної затримки. |
| ALL | Кожна репліка повинна відповідати. | Рідко. Один вузол не працює, і запит повністю не виконується. |
| БУДЬ (лише пише) | Натякнута передача вважається успішною, навіть якщо жодна репліка недоступна. | Максимальна доступність запису без послаблення довговічності. |
Сильна узгодженість гарантується, коли рівень читання плюс рівень запису перевищує коефіцієнт реплікації. З коефіцієнтом реплікації, рівним три, запис на рівні QUORUM та читання на рівні QUORUM задовольняє це правило, оскільки два плюс два більше за три. Запис на рівні ONE та читання на рівні ONE цього не задовольняють, і тому читання може повернути старіше значення.
Коли репліка недоступна, координатор зберігає натякати і відтворює його після повернення вузла, саме так ANY рівень та значна частина Cassandraробота над самовідновлювальною поведінкою.
Запис Operaв Cassandra
Координатор надсилає реплікам запит на запис. Якщо всі репліки готові, вони отримають запит на запис незалежно від рівня узгодженості.
Рівень консистенції визначає, скільки вузлів відповість підтвердженням успіху.
Вузол відповість підтвердженням успіху, якщо дані успішно записано в журнал фіксації та memTable.
Наприклад, в одному центрі обробки даних із коефіцієнтом реплікації, що дорівнює трьом, три репліки отримають запит на запис. Якщо рівень узгодженості дорівнює одиниці, лише одна репліка відповість із підтвердженням успіху, а решта дві залишатимуться неактивними.
Припустімо, якщо дві репліки, що залишилися, втратять дані через відключення вузлів або іншу проблему, Cassandra зробить ряд узгодженим завдяки вбудованому механізму ремонту Cassandra.
Тут пояснюється, як відбувається процес запису Cassandra,
- Коли запит на запис надходить до вузла, він перш за все реєструється в журналі комітів.
- Потім Cassandra записує дані в mem-таблицю. Дані, записані в mem-table під час кожного запиту на запис, також записуються окремо в журнал фіксації. Mem-table — це дані, які тимчасово зберігаються в пам’яті, тоді як журнал фіксації записує записи транзакцій для цілей резервного копіювання.
- Коли mem-table заповнюється, дані скидаються у файл даних SSTable.
Оскільки SSTables ніколи не редагуються на місці, видалення не видаляє рядок негайно. Натомість додається маркер, який називається надгробний пам'ятник записується, а рядок зникає лише тоді, коли стиснення виконується після пільгового періоду. Ось чому великі навантаження видалення уповільнюють читання, доки стиснення не наздожене його.
Читати Operaв Cassandra
Існує три типи запитів на читання, які координатор надсилає до реплік.
- Прямий запит
- Запит на дайджест
- Прочитайте запит на ремонт
Координатор надсилає прямий запит одній із реплік. Після цього координатор надсилає запит дайджесту до кількості реплік, визначених рівнем узгодженості, і перевіряє, чи є повернуті дані оновленими даними.
Після цього координатор надсилає запит на дайджест усім реплікам, що залишилися. Якщо будь-який вузол видає застаріле значення, запит на відновлення фонового читання оновить ці дані. Цей процес називається механізмом відновлення читання.
Усередині репліки, яка отримує прямий запит, порядок пошуку розроблено таким чином, щоб уникнути контакту з диском, де це можливо.
- Команда таблиця пам'яті перевіряється першим, оскільки найновіші записи ще не були скинуті.
- Команда кеш рядків, якщо ввімкнено, може відповісти на весь запит без подальшої роботи.
- A фільтр цвітіння запитується для кожної SSTable. Відповідає «точно немає» або «можливо, присутній», що дозволяє пропустити більшість SSTable без їх зчитування.
- Команда індекс розділу а його зведення визначає точне зміщення байта в будь-якій SSTable, яка пережила перевірку фільтра Блума.
- Збігаючі фрагменти з кількох SSTables об'єднуються, причому для кожного стовпця перемагає найновіша позначка часу.
Фільтр Блума – це крок, який забезпечує швидкість читання зі зростанням даних, оскільки він виключає майже кожну SSTable з розгляду, перш ніж відбудеться будь-який пошук на диску. Застосування цих механізмів на кількох машинах розглядається в Cassandra кластер навчальний посібник.
