Модель даних apache cassandra

Модель даних Cassandra складається з наступних елементів:

• стовпець або колонка (column) - осередок з даними, що включає 3 частини - ім'я (column name) у вигляді масиву байтів, мітку часу (timestamp) і саме значення (value) також у вигляді байтового масиву. З кожним значенням пов'язана мітка часу - задається користувачем 64-бітове число, яке використовується для вирішення конфліктів під час запису: чим воно більше, тим новіше вважається стовпець. Це враховується при видаленні старих колонок.

• рядок або запис (row) - іменована колекція стовпців;

• сімейство стовпців (column family) - іменована колекція рядків;

• простір ключів (keyspace) - група з декількох сімейств стовпців, зібраних разом. Воно логічно групує сімейства стовпців і забезпечує ізольовані області імен.

Також варто відзначити поняття порівнювача (comparator), що задається для імені стовпця і валідатора (validator) для значень і ключів.

Comparator визначає, які байтові значення припустимі для імен колонок і як їх впорядкувати, а validator - для значень колонок і ключів. Якщо вони не задані, то Кассандра зберігає значення і порівнює їх як байтові рядка (BytesType) так як, по суті, вони зберігаються всередині. Взагалі, в даній СУБД доступні наступні типи даних:

• BytesType: будь-які байтові рядки (без валідації);

• AsciiType: ASCII рядок;

• UTF8Type: UTF-8 рядок;

• IntegerType: число з довільним розміром;

• Int32Type: 4-байтовое число;

• LongType: 8-байтовое число;

• UUIDType: UUID 1-ого або 4-го типу;

• TimeUUIDType: UUID 1-ого типу;

• DateType: 8-байтовое значення мітки часу;

• BooleanType: два значення: true = 1 або false = 0;

• FloatType: 4-байтовое число з плаваючою комою;

• DoubleType: 8-байтовое число з плаваючою комою;

• DecimalType: число з довільним розміром і плаваючою комою;

• CounterColumnType: 8-байтовий лічильник.

Простір ключів відповідає поняттю схеми бази даних (database schema) в реляційної моделі, а що знаходяться в ньому сімейства стовпців - реляційної таблиці. Стовпці об'єднуються в запису за допомогою ключа (row key) у вигляді масиву байтів, за значенням якого стовпці впорядковані в межах одного запису. На відміну від реляційних СУБД, в NoSQL моделі можлива ситуація, коли різні рядки містять різну кількість колонок або стовпці з такими ж іменами, як і в інших записах

Можна сказати, конкретне значення, збережене в Apache Cassandra, ідентифікується наступними прив'язками:

• до додатка або предметної області в просторі ключів, що дозволяє на одному кластері розміщувати дані різних додатків;

• до запиту в рамках сімейства стовпців;

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

• до атрибуту в запису за допомогою імені колонки, що дозволяє в одному записі зберігати кілька значень..

Архітектура

Apache Cassandra - це децентралізована розподілена система, що складається з декількох вузлів, за якими вона розподіляє дані. На відміну від багатьох інших Big Data рішень екосистеми Apache Hadoop (HBase, HDFS), ця СУБД не підтримує концепцію master / slave (провідний / ведений), коли один з серверів є керуючим для інших компонентів кластера.

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

Завдяки такій розподіленої архітектурі, Кассандра надає наступні можливості:

• розподіл даних між вузлами кластера прозоро для користувачів - кожен сервер може приймати будь-який запит (на читання, запис або видалення даних), пересилаючи його на інший вузол, якщо запитувана інформацію зберігається не тут;

• користувачі можуть самі визначити необхідну кількість реплік, створення і управління якими забезпечить Cassandra;

• користувачами налаштовують рівень узгодженості даних по кожній операції зберігання і зчитування;

• висока швидкість запису (близько 80-360 МБ / с на вузол) - дані записуються швидше, ніж зчитуються за рахунок того, що їх більша частина зберігається в оперативній пам'яті відповідального вузла, і будь-які оновлення спершу виконуються в пам'яті, а тільки потім - в файлової системі. Щоб уникнути втрати інформації, всі транзакції фіксуються в спеціальному журналі на диску. При цьому, на відміну від поновлення даних, записи в журнали фіксації тільки додаються, що виключає затримку при обертанні диска.

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

Таким чином, відсутність центрального вузла позбавляє Кассандру головного недоліку, властивого системам master / slave, в яких відмовляє весь кластер при збої головного сервера (Master Node).

У кластері Cassandra всі вузли рівноцінні між собою і, якщо один з них відмовив, його функції візьме на себе якийсь з решти. Завдяки такій децентралізації Apache Cassandra відмінно підходить для географічно розподілених систем з високою доступністю, розташованих в різних датацентрах. Однак, при всіх перевагах такої гнучко масштабується архітектури, вона обумовлює особливості операцій читання і запису, а також накладає ряд істотних обмежень на використання цієї СУБД в реальних Big Data проектах.