МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
ПВНЗ «Міжнародний Науково-Технічний Університет» імені Юрія Бугая
Факультет: Інженерія програмного забезпечення
На тему
“ Apache Cassandra”
Студента групи ПІк-91
Лободи Олега Олеговича
Викладач
Проскудіна Галина Юріївна
Місто Київ 2020
ЗМІСТ
ВСТУП………………………………………………………………………………..3
APACHE CASSANDRA. CQL……………………………………………………....3
МОДЕЛЬ ДАНИХ APACHE CASSANDRA……………………………………….4
АРХІТЕКТУРА………………………………………………………………………5
ПЕРЕВАГИ APACHE CASSANDRA…………………………………………….....6
НЕДОЛІКИ APACHE CASSANDRA………………………………………………8
ПРИКЛАДИ ВИКОРИСТАННЯ APACHE CASSANDRA………………………..9
ВИСНОВКИ………………………………………………………………………...10
ДЖЕРЕЛА…………………………………………………………………………..11
ВСТУП
Apache Cassandra - це нереляційна відмовостійка розподілена СУБД, розрахована на створення високомасштабуємих і надійних сховищ величезних масивів даних, представлених у вигляді хешу.
Спочатку проект був розроблений в надрах Facebook і в 2009 році переданий під крило фонду Apache Software Foundation, ця організація продовжує розвиток проекту. Промислові рішення на базі Cassandra розгорнуті для забезпечення сервісів таких компаній, як Cisco, IBM, Cloudkick, Reddit, Digg, Rackspace, Apple, Twitter і Spotify.
APACHE CASSANDRA. CQL
Написана на мові Java, реалізує розподілену хеш-систему, схожу з DynamoDB, що забезпечує практично лінійну масштабованість при збільшенні обсягу даних. Використовує модель зберігання даних на базі сімейства стовпців, чим відрізняється від систем, подібних MemcacheDB, які зберігають дані тільки в зв'язці «ключ - значення», можливістю організувати зберігання хешу з декількома рівнями укладення.
Відноситься до категорії стійких до відмов СУБД: поміщені в базу дані автоматично реплицируются на кілька вузлів распредёленной мережі або навіть рівномірно розподіляються в декількох дата-центрах, при збої вузла його функції на льоту підхоплюються іншими вузлами, додавання нових вузлів в кластер і оновлення версії Cassandra проводиться на льоту, без додаткового ручного втручання і переконфігурації інших вузлів.
Для спрощення взаємодії з базою даних підтримується мова формування структурованих запитів CQL (Cassandra Query Language), котра в якійсь мірі схожа з SQL, але істотно урізана по функціональним можливостям. Наприклад, можна виконувати тільки найпростіші запити SELECT з вибіркою за певним умові. Додавання і оновлення здійснюється через єдине вираження UPDATE, операція INSERT відсутня (якщо записи немає, при виконанні UPDATE вона створюється - використовується семантика SQL-оператора MERGE).
З відмітних можливостей - підтримка просторів імен і сімейств стовпців, створення індексів через вираз «CREATE INDEX». Драйвери з підтримкою CQL реалізовані для мов:
Python (DBAPI2),
Java (JDBC),
Ruby (gem cassandra-cql),
PHP (Thrift, cassandra-pdo, Cassandra-PHP-Client-Library),
JavaScript (Node.js),
Perl (DBD :: Cassandra).
Крім того, CQL реалізована в СУБД Scylla, яка архітектурно і лінгвістично повторює систему Cassandra, але написана на C ++ з метою підвищення показників продуктивності.
Модель даних 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 проектах.
масштабованість і надійність в зв'язку з відсутністю центрального сервера (Master Node), відмова якого може стати причиною збою всього кластера, як у випадку HBase. Додати нові вузли в кластер і оновити версії Cassandra можна на льоту, без додаткового ручного втручання і переконфігурації всього кластера. Однак, на практиці рекомендується заново згенерувати ключі (токени) для кожного вузла, включаючи існуючі, щоб зберегти якість розподілу навантаження. Генерації ключів для існуючих вузлів можна уникнути в разі кратного збільшення кількості вузлів (двічі, тричі і т.д.). Також варто відзначити 3 механізму відновлення даних:
читання з відновленням (read repair), коли під час читання дані запитуються з усіх реплік і порівнюються після координації. Та колонка, яка має останню мітку часу, пошириться на вузли з застарілими мітками.
спрямована відправка (hinted handoff), яка зберігає інформацію про операції записи на координатора навіть якщо запис на якомусь вузлі не вийшло. Потім, по можливості, цей запис знову повториться. Такий механізм дозволяє швидко відновити дані у разі короткострокового відсутності вузла в кластері. Крім того, при рівні узгодженості ANY він дозволяє домогтися повної доступності для запису (absolute write availability) навіть при недоступності всіх вузлів-реплік - операція запису підтверджується, а дані збережуться на вузлі-координатора.
анти-ентропійне відновлення вузла (anti-entropy node repair) - регулярно запускається вручну процес відновлення всіх реплік, який дозволяє відновити дані, якщо вони не були відновлені двома вищеописаними способами.
гнучка схема даних, заснована на комбінації столбцових сімейств (Column Family) в простір ключів (keyspace), дозволяючи визначати в рядках однієї і тієї ж таблиці різні стовпці і таким чином ефективно зберігати виряджені таблиці. При цьому в одній таблиці може бути до двох мільйонів стовпців, що вельми актуально для Big Data систем.
висока пропускна здатність, особливо для операцій запису (близько 80-360 МБ / с на вузол) - завдяки зберіганню в оперативній пам'яті відповідального вузла, дані записуються швидше, ніж зчитуються. Крім того, за рахунок використання LSM-дерев, Сassandra також дозволяє досить-таки швидко зчитувати дані. Нагадаємо, LSM-дерево (Log-structured merge-tree, журнально-структуроване дерево зі злиттям) - це структура даних, яка зберігає пари «ключ - значення» і надає швидкий доступ за індексом в умовах частих запитів на вставку, наприклад, при зберіганні журналів транзакцій.
власна SQL-подібна мова запитів (CQL, Cassandra Query Language), яка дозволяє виконувати найпростіші запити SELECT з вибіркою за певним умові. Додавання і оновлення здійснюється через єдине вираження UPDATE, операція INSERT відсутня. Також CQL підтримує простір імен і сімейств стовпців. Драйвери з підтримкою цієї мови запитів реалізовані для мов Python, Java, Ruby, PHP, JavaScript і Perl.
наявність інструментів розширення функціональних можливостей - певні користувачем типи даних (UDT, User Defined Types), починаючи з версії 2.1, а в релізі 2.2 можна писати збережені процедури і агрегати.
підтримка пошуку за рахунок вторинних індексів, створити які можна за допомогою CQL-вирази CREATE INDEX;
настроюється узгодженість і підтримка реплікації, коли користувачі можуть самі визначити необхідну кількість реплік і задати рівень узгодженості даних по кожній операції зберігання. Зокрема, при кожному читанні і запису клієнт може вказати бажаний рівень узгодженості (консистентності) - ANY, ONE, TWO, THREE, QUORUM, SERIAL, ALL і інші. Наприклад, яка буде використовуватися під рівень ONE каже, що запит повинен дійти хоча б до одного вузла, що відповідає за зберігання рядки, а QUORUM - що запит має отримати більшість вузлів, наприклад, 2 з 3. Це дозволяє вибирати між швидкістю виконання запитів і надійністю. Для більшості завдань саме ONE є цілком відповідним рівнем узгодженості.
автоматичне вирішення конфліктів завдяки зберіганню тимчасових міток (timestamp) для кожного стовпця в будь-якому записі. Наприклад, якщо одночасно робляться два запити на зміну значень різних стовпців запису, то можливий конфлікт на вузлах, що відповідають за зберігання цього рядка. Конфлікт буде успішно вирішено за часом останньої зміни стовпців.
підтримка аутентифікації, ролей і роботи з клієнтом по захищеному криптографічного протоколу SSL.
підтримка ACID-транзакційності на рівні запису, тобто для набору стовпчиків з одним ключем:
Atomicity (атомарність) - всі стовпці в одному записі за одну операцію будуть записані;
Consistency (узгодженість) - можна задати рівень суворої узгодженості;
Isolation (ізольованість) - починаючи з версії 1.1, з'явилася підтримка ізольованості, коли під час запису стовпців одного рядка інший користувач, який читає цю ж рядок, побачить повністю стару версію запису або, вже після закінчення операції, нову версію, а не частина колонок з однієї і частина з другої;
Durability (довговічність), що забезпечується наявністю журналу фіксацій, який буде відтворено і відновить відмовив вузол кластера до потрібного стану.