Особливості NoSQL баз даних

1. Слабкі ACID властивості

Довгий час консистентність (consistency) даних була “священною коровою” для архітекторів та розробників. Усі реляційні бази забезпечували той чи інший рівень ізоляції — або за рахунок блокувань під час зміни та блокуючого читання, або за рахунок undo-логів. З приходом величезних масивів інформації та розподілених систем стало зрозуміло, що забезпечити для них транзакційність набору операцій з одного боку та отримати високу доступність та швидкий час відгуку з іншого неможливо.

Ба більше, навіть оновлення одного запису не гарантує, що будь-який інший користувач моментально побачить зміни в системі, адже зміна може статися, наприклад, у майстер-ноді, а репліка асинхронно скопіюється на слейв-ноду, з якою працює інший користувач. У такому разі він побачить результат через якийсь проміжок часу. Це називається eventual consistency і це те, на що йдуть зараз усі найбільші інтернет-компанії світу, включно з Facebook та Amazon. Останні з гордістю заявляють, що максимальний інтервал, протягом якого може бачити неконсистентні дані становлять не більше секунди. Приклад такої ситуації показано на малюнку:

Логічне питання, яке постає в такій ситуації: а що робити системам, які класично ставлять високі вимоги до атомарності-консистентності операцій і водночас потребують швидких розподілених кластерів — фінансових, інтернет-магазинів тощо? Практика показує, що ці вимоги вже давно неактуальні: ось що сказав один розробник фінансової банківської системи: “Якби ми дійсно чекали завершення кожної транзакції у світовій мережі ATM (банкоматів), транзакції займали б стільки часу, що клієнти втікали б геть. Що відбувається, якщо ти і твій партнер винаймаєте гроші одночасно і перевищуєте ліміт? — Ви обидва отримаєте гроші, а ми виправимо це пізніше.”

Інший приклад — бронювання готелів, показаний на зображенні. Онлайн-магазини, чия політика роботи з даними передбачає eventual consistency, зобов'язані передбачити заходи на випадок таких ситуацій (автоматичне вирішення конфліктів, відкат операції, оновлення з іншими даними). На практиці готелі завжди намагаються тримати пул вільних номерів на непередбачений випадок і це може стати вирішенням спірної ситуації.

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

2. Розподілені системи без спільно використовуваних ресурсів (share nothing)

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

Це, мабуть, головний лейтмотив розвитку NoSQL баз. З лавиноподібним зростанням інформації у світі та необхідності її обробляти за розумний час постала проблема вертикальної масштабованості — зростання швидкості процесора зупинилося на 3.5 ГГц, швидкість читання з диска також зростає тихими темпами, плюс ціна потужного сервера завжди більша за сумарну ціну кількох простих серверів. У цій ситуації звичайні реляційні бази, навіть кластеризовані на масиві дисків, не здатні вирішити проблему швидкості, масштабованості та пропускної спроможності.

Єдиний вихід із ситуації — горизонтальне масштабування, коли кілька незалежних серверів з'єднуються швидкою мережею і кожен володіє/обробляє лише частину даних та/або лише частину запитів на читання-оновлення. У такій архітектурі підвищення потужності сховища (ємності, часу відгуку, пропускної спроможності) необхідно лише додати новий сервер в кластер — і все. Процедурами шардингу, реплікації, забезпеченням відмовостійкості (результат буде отримано навіть якщо один або кілька серверів перестали відповідати), перерозподіл даних у разі додавання ноди займається сама NoSQL база.

Стисло представлю основні властивості розподілених NoSQL баз:

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

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

Шардинг — розділення даних по сайтам:

Шардинг часто використовувався як “костиль” до реляційних баз даних з метою збільшення швидкості та пропускної спроможності: додаток користувача партикувало дані по кількох незалежних баз даних і під час запиту відповідних даних користувачем звертався до конкретної бази. У NoSQL базах даних шардинг, як і реплікація, виробляються автоматично самою базою і застосунок користувача відокремлено від цих складних механізмів.

3. NoSQL бази в основному оупенсорсні і створені в 21 столітті

Саме за другою ознакою Садаладж і Фаулер не класифікували об'єктні бази даних як NoSQL (хоча http://nosql-database.org/ включає їх до загального списку), оскільки вони були створені ще в 90-х і так і не здобули великої популярності.

NoSQL рух набирає популярності гігантськими темпами. Однак це не означає, що реляційні бази даних стають рудиментом чи архаїчними. Швидше за все, вони будуть використовуватися, як і раніше, активно, але все більше в симбіозі з ними будуть виступати NoSQL бази. Ми вступаємо в епоху polyglot persistence — епоху, коли для різних потреб використовуються різні сховища даних. Тепер немає монополізму реляційних баз даних як безальтернативного джерела даних. Все частіше архітектори вибирають сховище, виходячи з природи самих даних і того, як ми ними хочемо маніпулювати, які обсяги інформації очікуються. І тому все стає лише цікавішим.

Нижче ми спробуємо розібратися в роботі розподіленої бази даних на прикладі NoSQL СУБД Cassandra…