Посібник з NoSQL для розробників

Якщо ви стежите за тенденціями у сферах backend-розробки та Big Data, то, ймовірно, вже звернули увагу на галас навколо баз даних NoSQL , характерну для останніх років. Когось такий підхід до БД надихає, комусь здається, що в ньому прихований якийсь трюк: моделі даних у них не такі, як у звичних реляційних базах, інтерфейси програмування додатків незвичні, а програми найчастіше незрозумілі. У цій статті я розповім, чому вони взагалі були створені, ці бази даних NoSQL, які завдання вони вирішують і чому раптом потрібно так багато різних баз даних. Якщо ви новачок в NoSQL, вас може особливо зацікавити остання частина статті, в якій перераховуються бази даних цього типу, які, на мою думку, варто вивчити перш за все, щоб отримати повне уявлення про цю область.

Навіщо нам раптом потрібна нова база даних?

Ви можете здивуватися: а що не так з реляційними базами даних? Справа в тому, що вони справді чудово працювали протягом багатьох років, але тепер постала проблема, з якою вони більше не можуть упоратися. Згідно з деякими передбаченнями, у 2018 році людство генеруватиме 50000 гігабайт даних за секунду. Це величезний обсяг даних! Його зберігання та обробка є серйозним інженерним викликом. А ще страшніше те, що цей обсяг постійно зростає. Як виявилося, реляційні бази даних погано пристосовані до роботи з справді великими обсягами даних. Вони спроектовані для роботи на одній машині, і якщо ви хотіли б обробляти більшу кількість запитів, то єдиний варіант - купити комп'ютер з великою кількістю оперативної пам'яті та потужнішим процесором. На жаль, кількість запитів, які здатна обробити одна машина, обмежена, а для розподіленої роботи на кількох машинах нам потрібна інша технологія баз даних. Звичайно, деякі з читачів у цей момент посміхнуться і скажуть, що існує два широко поширені методи використання кількох машин у разі реляційної бази даних: реплікація та шардинг. Воно так, але цих методів недостатньо, щоб упоратися з нашими завданнями. Реплікація читання – методика, коли кожне оновлення бази даних поширюється інші машини, які можуть опрацьовувати лише запити на читання. У цьому випадку всі зміни виконуються одним сервером, який називається провідним вузлом, тоді як інші сервери, які називають репліками читання, лише підтримують копії даних. Користувач може читати з будь-якої машини, але змінювати дані лише через провідний вузол. Це зручний і дуже популярний метод, але дозволяє лише обробляти більше запитів на читання і ніяк не вирішує завдання обробки необхідних обсягів даних. Шардинг – ще один популярний підхід, у якому використовується кілька екземплярів реляційної бази даних. Кожен з них обробляє операції запису та читання для частини даних. Якщо в базі даних зберігається, наприклад, інформація про покупців, за допомогою шардингу одна машина може обробляти всі запити про покупців, імена яких починаються на A, інша – зберігати всі дані про покупців, чиї імена починаються на B, і так далі. Хоча шардинг дозволяє записувати більше даних, керування такою базою даних - справжній кошмар: доводиться вирівнювати дані по машинах і масштабувати кластер в обидві сторони за необхідності. Хоча теоретично це виглядає просто, правильна реалізація – дуже складне завдання.

Чи можна удосконалити реляційні бази даних?

Думаю, ви вже повірабо в те, що реляційні бази даних не найкраще пристосовані до обсягів даних, що генеруються в сучасному світі. Хоча, можливо, ви все ще дивуєтесь, чому ніхто досі не створив "поліпшеної" реляційної бази даних, яка могла б ефективно працювати на кількох машинах. Може здатися, що ця технологія просто ще не розроблена, і незабаром з'являться розподілені реляційні бази даних. На жаль, цього не станеться. Це неможливо з точки зору математики, і нічого вдіяти з цим не можна. Щоб зрозуміти чому це так, необхідно звернутися до так званої теореми CAP (вона ж теорема Брюера). Її довели в 1999 році, і вона стверджує, що у розподілена база даних, що працює на декількох машинах, може мати наступні три властивості: Узгодженістю ( C onsistency) – у результаті будь-якої операції читання повертаються результати останньої відповідної операції запису. Якщо система узгоджена, після запису нових даних, прочитати старі вже перезаписані неможливо. Доступністю ( A vailability) – розподілена система у будь-який момент може обслужити вхідний запит і повернути неправильну відповідь. Стійкістю до порушення зв'язності ( Partition tolerance) – база даних продовжує відповідати запити читання і запис навіть у разі, коли частина її серверів тимчасово нездатні взаємодіяти друг з одним. Цей тимчасовий збій називається порушенням зв'язності мережі і може викликатися безліччю фактором, починаючи від фізичних проблем з мережею через сервер, що повільно працює, і закінчуючи фізичним пошкодженням мережевого обладнання. Всі ці властивості, безумовно, зручні, і нам дуже хотілося б, щоб база даних поєднувала їх все. Жоден розсудливий розробник не захоче відмовитися від, скажімо, доступності, не отримавши нічого натомість. На жаль, теорема CAP також стверджує, що одночасне виконання всіх трьох властивостей неможливе. Зрозуміти це може бути непросто, але можливо. По-перше, якщо нам потрібна розподілена база даних, вона повинна бути "стійкою до порушення зв'язності". Це навіть не обговорюється. Порушення зв'язності відбуваються весь час і наша база даних має працювати, попри це. Тепер давайте зрозуміємо, чому ми не можемо досягти одночасно узгодженості та доступності. Уявіть, що у нас є проста база даних, що працює на двох машинах: A і B. Будь-який користувач може виконувати запис на будь-яку з машин, після чого дані копіюються на іншу. Тепер уявіть собі, що ці машини тимчасово втратабо можливість обміну повідомленнями один з одним, і машина B не може надсилати дані на машину A або отримувати дані від неї. Якщо в цей проміжок часу машина B отримає запит на читання від клієнта, вона має дві можливості:

1. Повернути свої локальні дані, навіть якщо вони не найсвіжіші. У цьому випадку надається перевага доступності (повернути хоч якісь дані, навіть застарілі).
2. Повернути помилку. В цьому випадку віддається перевага узгодженості: клієнт не отримає застарілі дані, але й не отримає взагалі жодних.

Реляційні бази даних прагнуть реалізувати властивості "узгодженості" і "доступності" одночасно, і, отже, не можуть працювати в розподіленому середовищі. Спроба реалізувати всі можливості реляційної бази даних у розподіленій системі виявиться або нереалістичною, або просто нездійсненною . З іншого боку, бази даних NoSQL надають основне значення масштабованості та продуктивності. У них зазвичай відсутні такі "базові" можливості, як з'єднання та транзакції, а модель даних виявляється зовсім іншою, можливо, в чомусь навіть обмежує. Все це дає можливість зберігання більших обсягів даних та обробки більшої кількості запитів, ніж було можливо колись раніше.

Як базам даних NoSQL вдається поєднувати узгодженість та доступність?

Вам може здаватися, що вибравши NoSQL БД, ви завжди отримуватимете або якісь застарілі дані, або помилку у разі будь-якого збою. Насправді ж, доступність і узгодженість — аж ніяк не єдині можливі варіанти. Існує широкий спектр доступних для вибору варіантів. У реляційних базах даних цих параметрів немає, але NoSQL дозволяє керувати виконанням запитів подібним чином. Так чи інакше вони дозволяють задавати два параметри при виконанні операцій запису або читання в NoSQL базі даних: W – скільки машин у кластері повинно підтвердити збереження даних при виконанні операції запису . Чим більша кількість машин, куди ви запишете свої дані, тим легше буде прочитати найсвіжіші дані при наступній операції читання, але й тим більше часу це займе. R - з якої кількості машин ви хотіли б читати дані . У розподіленій системі поширення даних по всіх машинах кластера може зайняти деякий час, так що на деяких серверах дані будуть актуальними, а інші відставатимуть. Чим більша кількість машин, з яких читаються дані, тим вищі шанси прочитати актуальні дані. Розглянемо практичний приклад. Якщо у вашому кластері п'ять комп'ютерів, і ви вирішабо записувати дані лише на один, а потім читати дані з одного випадково вибраного комп'ютера, з ймовірністю 80% ви прочитаєте застарілі дані. З іншого боку, при цьому використовуватиметься мінімум ресурсів. Так що, якщо застарілі дані вас влаштовують, це не такий поганий варіант. У цьому випадку параметри W та R дорівнюють 1. З іншого боку, якщо ви записуєте дані на всі п'ять машин у базі даних NoSQL, можете читати дані з будь-якої машини, і щоразу гарантовано отримаєте актуальні дані. Виконання тієї ж операції при більшій кількості машин займе довше, але якщо актуальні дані для вас важливі, то можна вибрати цей варіант. У цьому випадку W = R = 5. Яка мінімальна кількість операцій читання та запису, необхідна для узгодженості бази даних? Ось проста формула: R + W ≥ N + 1 де N - число машин в кластері. Це означає, що при п'яти серверах можна вибрати або R = 2 і W = 4, або R = 3 і W = 3 або R = 4 і W = 2. У цьому випадку не має значення, на які машини записуються дані, читання завжди буде вироблятися принаймні з однієї машини з актуальними даними. В інших баз даних, наприклад DynamoDB, обмеження відрізняються, і вони дозволяють лише узгоджені операції запису. Кожен елемент даних зберігається на трьох серверах, і при записі будь-яких даних він записується на дві машини з трьох. Але при читанні даних можна вибрати один із двох варіантів:

1. Суворе читання, при якому дані читаються з двох машин з трьох і завжди повертаються останні записані дані.
2. Читання, узгоджене в кінцевому рахунку, при якому вибирається випадково одна машина, з якої читаються дані. Однак можуть тимчасово повертатися застарілі дані.

Чому існує так багато баз даних NoSQL?

Якщо ви стежите за останніми новинами в галузі розробки програмного забезпечення, то напевно чули про безліч різних NoSQL баз даних, наприклад MongoDB, DynamoDB, Cassandra, Redis та багатьох інших. Можливо, ви здивуєтеся: навіщо потрібно так багато різних NoSQL баз даних? Причина проста: різні бази даних NoSQL призначені для вирішення різних завдань. Саме тому кількість конкуруючих баз даних така велика. NoSQL бази даних поділяються на чотири основні категорії:

Документно-орієнтовані бази даних

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

Бази даних типу "ключ/значення"

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

Графові бази даних

Багато предметних областей, наприклад, соціальні мережі або інформацію про фільми та акторів, можна подати у вигляді графів. Хоча граф можна уявити і за допомогою реляційної бази даних, це складно та незручно. Якщо вам потрібні графові дані, краще скористатися спеціалізованою графовою базою даних, яка може зберігати інформацію про графу у розподіленому кластері та дає можливість ефективної реалізації алгоритмів на графах.

Стовпцеві бази даних

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

Яку базу даних вибрати?

Вибір бази даних – зазвичай болісна проблема, і за такої кількості можливих варіантів може здатися нездійсненним завданням. Хороша новина полягає в тому, що немає потреби обирати лише одну. Замість створення єдиного монолітного додатка, що реалізує всі можливості та має доступ до всіх даних системи, можна скористатися ще одним сучасним патерном під назвою " мікросервіси ": розбити додаток на набір незалежних сервісів. Кожен сервіс вирішує своє вузьке завдання і використовує тільки свою базу даних, яка максимально підходить для вирішення цього завдання.

Як накажете все це вивчити?

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

1. MongoDB . Мабуть, найпопулярніша NoSQL база даних на ринку. Якщо компанія не використовує як основне сховище даних реляційну базу даних, то, ймовірно, вона використовує MongoDB. Це гнучке сховище документів із гарним набором інструментарію. На початку своєї "кар'єри" у MongoDB була не найкраща репутація, тому що дані в ній в деяких випадках губабося , але з того часу її стабільність і надійність набагато підвищабося. Погляньте на цей присвячений MongoDB курс , якщо хочете дізнатися більше.


2. DynamoDB . Якщо ви використовуєте веб-сервіси Amazon (AWS), вам краще дізнатися більше про DynamoDB. Це виключно надійна база даних з низькою затримкою, багатим набором можливостей та інтеграцією з безліччю інших сервісів AWS. А найприємніше те, що її не потрібно розгортати самостійно. Налаштувати масштабований кластер DynamoDB, здатний обробляти тисячі запитів, можна лише за кілька клацань мишею. Якщо це вас зацікавило, можете поглянути на цей курс .


3. Neo4j . Найпоширеніша графова база даних. Це масштабоване і стабільне рішення, яке підходить для бажаючих скористатися графовою моделлю даних. Якщо хочете дізнатися більше – почніть із цього курсу .


4. Redis . У той час як інші описані тут бази даних використовуються для зберігання основних даних програми, Redis застосовується в основному для реалізації кешу та зберігання допоміжних даних. У багатьох випадках використовується одна з вищезгаданих баз даних у тандемі з Redis. Щоб дізнатися більше, завітайте до цього курсу.

У 2018-му з NoSQL

NoSQL бази даних – широка область, що швидко розвивається. Вони дозволяють зберігати та обробляти нечувані досі обсяги даних, але за це доводиться платити. У цих базах даних немає багатьох звичних за реляційними базами даних можливостей, і налаштувати себе на їх використання може виявитися непросто. Але коли ви з ними розберетеся, зможете створювати масштабовані розподілені бази даних, здатні обробляти разючі обсяги запитів на читання і запис, що може мати виняткове значення в міру генерації все більших і більших обсягів даних. Оригінал: https://simpleprogrammer.com/guide-nosql-software-developers/