Досить давненько вже побачила матеріал по NoSQL до цієї статті та ось нарешті є переклад:

У багатьох джерелах визначення NoSQL бази даних подається досить неоднозначно, що у свою чергу спричиняє невірне або неповне уявлення змісту цього різновиду баз даних. Й сама суть терміну NoSQL бази даних збиває з пантелику — так як під визначення “неживі предмети” можуть потрапляти камінь, лампочка і автомобіль — однаково поняття NoSQL буває пов’язує між собою програмні рішення, теж абсолютно не аналогічні.

У даній статті мова піде про NoSQL бази даних, які були спроектовані й створені після масового впровадження реляційних баз даних (SQL). Логічно у цьому контексті поняття NoSQL може включати в себе і не зовсім NoSQL бази даних, дореляційні БД, які проектувалися без огляду на досвід використання SQL систем і не мали на меті свого часу створення сучасних NoSQL рішень. Їх мета була більше експериментальна, а саме спробувати усунути деякі відомі недоліки SQL й досягти більш високої продуктивності в конкретних завданнях.

Причини виникнення NoSQL баз даних

Ключовим фактором, який змусив світову IT-спільноту задуматися над новими стратегіями зберігання і доступу до інформації, стало планомірне зростання обсягів даних у мережі Інтернет. У зв’язку з цим з’явилося Big Data. Big Data — це стратегія ефективної праці з величезними постійно зростаючими масивами даних.

І на тлі Big Data концепції чітко вимальовувалася необхідність в моделі бази даних, яка буде більше націлена на швидкість доступу і масштабованість. Потрібно було якесь більш просте рішення, аніж існуючі реляційні БД, при цьому не поступалися їм у ефективності вирішення конкретних завдань. В першу чергу, це завдання побудови хмарних сховищ, де кінцевому користувачеві в першу чергу важлива швидкість доступу і можливий обсяг інформації, що там зберігатиметься.

Історія популярності NoSQL

Пік найактивнішого обговорення NoSQL баз даних припав на 2009 рік. Цей період приніс безліч міфів і спірних теорій. Розглянувши їх, можна уявити собі шлях NoSQL рішень і уявлення про них в головах людей.

NoSQL — це революція

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

Принципово новими підходами NoSQL рішення теж не можуть масово похвалитися — наприклад, концепція запущеної в 2008 році MongoDB — це більш ефективна реалізація моделі роботи БД Pick 1965 го року випуску.

SQL бази даних приречені

Подібні розмови ведуться вже майже другий десяток років, ба як і раніше реляційні БД тримають домінуючі позиції на ринку з величезним відривом від будь-яких NoSQL рішень. Це відбувається в першу чергу через те, що NoSQL бази даних не можуть суттєво більш ефективно вирішувати завдання аніж SQL. Найбільш вдалі NoSQL рішення, в першу чергу, націлені на вирішення специфічних завдань і створюються гігантами IT-індустрії для власних потреб — це продукти від Google, Amazon, Microsoft і Apache, які обслуговують конкретні проекти. Google AppEngine Data Store можливо використовувати стільки з веб-сервісами Google, сховище SQL Data Services є частиною платформи Microsoft Azure, а SimpleDB входить до складу Amazon WebServices.

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

Весь галас навколо NoSQL і Big Data — це обман

Проте і в надто критичні відгуки про NoSQL не варто повністю вірити. Віяння нереляційних баз даних принесло з собою безліч цікавих і комерційно успішних ідей для потреб різних компаній. Є безліч проектів, які можуть отримати вигоду з роботи з NoSQL системами, але їх творці повинні тверезо оцінювати довгострокові перспективи впровадження нереляційних баз даних. Так, всі ці рішення досить молоді, і безліч компаній зазнали прикрої невдачі, прийнявши невірне рішення на хвилі моди. Але чийсь поганий досвід не є фактичним недоліком продукту.

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

Види NoSQL баз даних

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

Бази даних виду “ключ-значення”

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

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

Саме тому подібні сбази даних використовуються в тих випадках, коли конкретний вміст окремої комірки не цікаво оператору бази даних – інакше кажучи, повністю відсутні зв’язку між окремими осередками сховища. Бази даних типу “ключ-значення” не дуже добре підходять у якості повної заміни реляційних БД, але знайшли своє застосування в якості кешей для об’єктів, адже між кешуванням об’єктів різних користувачів однаково немає зв’язків, важлива лише швидкість доступу до кешу, а так ж можливість швидко змінювати масштаб системи.

Найбільш відомі приклади СУБД даного типу це Amazon DynamoDB, Berkeley DB, MemcacheDB, Redis і Riak.

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

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

Наприклад, при створенні музичного сховища можна створити колекцію музики 80-х років, в ній зробити окремі колекції по роках, а всередині них окремі документи з треками випущених в цей рік альбомів. Але якщо користувач побажає побачити рейтинг найпопулярніших композицій певного десятиліття — цей запит буде виконуватися досить довго, адже доведеться переглянути кожен документ всієї бази даних. Таким чином, можна зробити висновок що документоорієнтовані БД знайдуть своє застосування в задачах, де потрібно впорядковане зберігання інформації, але немає безлічі зв’язків між даними і не потрібно постійно збирати статистику по ним. Документи не вимагають визначення схеми — це значить що кожен окремий документ може складатися з будь-якої кількості унікальних полів — на відміну від реляційних баз даних, в яких при спробі зберігати різнорідні дані неминуче з’являються порожні поля.

Приклади СУБД даного типу: CouchDB, Couchbase, MarkLogic, MongoDB, eXist.

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

Графова модель бази даних являє собою узагальнення мережевий моделі даних і відрізняється сильними зв’язками між вузлами. Графові бази даних найкраще підходять для реалізації проектів, які передбачають природну графову структуру даних. В першу чергу соціальних мереж, а так само для створення семантичних павутини. У подібних завданнях вони сильно випереджають реляційні БД по продуктивності, простоті внесення змін і наочності подання інформації. У деяких баз даних існують механізми спеціальної оптимізації для роботи з SSD-накопичувачами. Для роботи з досить великими графами використовуються алгоритми, які передбачають часткове приміщення графа в оперативну пам’ять. Найбільш відомі графові СУБД це ArangoDB, FlockDB, Giraph, HyperGraphDB, Neo4j, OrientDB.

Bigtable-подібні бази даних

Bigtable-подібні бази даних чи інакше сховища сімейств колонок містять дані, впорядковані у вигляді розрідженій матриці, рядки і стовпці якої використовуються в якості ключів. Ці сховища мають багато спільного з документоорієнтованими Базами Даних — системами керування вмістом (CRM), Event агрегаторами реєстрації на події, блоги. Не варто плутати bigtable-подібні бази даних з лінійними сховищами, які є, по суті, реляційними БД з роздільним зберіганням колонок.

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

Прикладами СУБД даного типу є: HBase, Cassandra, Hypertable, SimpleDB.

Сильні і слабкі сторони NoSQL

Щоб зрозуміти основну причину популярності NoSQL рішень, а також позначити сферу їх розумного застосування варто розглянути всі запропоновані варіанти з декількох сторін: виділити загальні відмінності всіх NoSQL систем від реляційних БД, а так само обговорити ті проекти, в яких NoSQL бази даних будуть сильніші за рахунок конструктивних особливостей.

Відсутність SQL

Перша особливість вельми очевидна — це відсутність SQL (Structured Query Language) універсальної мови запитів, який використовується усіма реляційними системами. Все NoSQL системи мають власний API для взаємодії або вбудовану мову запитів, часто є просто урізаною версією SQL. Це рішення має свої позитивні сторони:

  • Простота роботи. Багато NoSQL баз даних, в основному сховищі виду “ключ-значення” мають у порівнянні з реляційними базами даних дуже сильно урізану функціональність, яка їм просто не потрібна для виконання поставлених завдань. В такому випадку оператору бази даних не потрібно глибоких знань досить потужного і гнучкого механізму роботи з SQL-запитами. Це дуже сильно знижує вхідний поріг для початку роботи з NoSQL сховищами.
  • Простіший синтаксис запитів — менше помилок. Для спрощення роботи з базою даних деякими розробниками використовується ORM (Object-Relational Mapping)  (Object-Relational Mapping) — це технологія, що дозволяє автоматично транслювати операції з об’єктами в запити до бази даних. Найчастіше подібні рішення працюють неефективно і плодять безліч непотрібних або відверто помилкових запитів. Не можна сказати, що розробники ORM погано виконують свою роботу, просто завдання занадто складне. Мова SQL універсальна, проте дуже ємна, для повноцінної роботи з нею необхідний певний багаж знань. При цьому власні мови запитів сучасних NoSQL сховищ набагато більше підходять для виконання простих маніпуляцій з базою даних.

Недоліки у даного рішення так само присутні, притому в довгостроковій перспективі вони можуть серйозно переважити всі позитивні моменти:

  • Додаток сильно прив’язується до конкретної СУБД. Мова SQL універсальна для всіх реляційних баз даних і користувачеві не доведеться кардинально переписувати весь код у разі зміни СУБД. Навіть якщо дві NoSQL системи концептуально практично не відрізняються, вони будуть мати дуже мало загальних стандартів в API і в специфіці запитів.
  • Обмежена ємність вбудованої мови запитів. SQL має дуже багату історію і безліч стандартів. Це дуже потужний і складний інструмент для операцій з даними і складанням звітів. Практично всі мови запитів і методи API сховищ NoSQL були створені на основі тих чи інших функцій SQL — як наслідок, вони мають значно меншу функціональність.
  • Низька цінність і вузькопрофільність знань — фахівців з хорошим знанням SQL набагато простіше знайти, в той час коли специфікою роботи API деяких NoSQL рішень на серйозному рівні мало хто захоплюється — це значить, що багато специфічних моментів оператору бази даних доведеться освоювати “на ходу”.

Простота і молодість NoSQL

Якщо переваги простоти NoSQL сховищ досить очевидні, то недоліки часто з’ясовуються лише з гірким досвідом. По-перше, обмеження структури реляційних БД певною мірою гарантують цілісність даних — інформація, яка не задовольняє обмеженням по типу, просто не зможе потрапити в базу даних. У разі використання, наприклад, сховищ типу “ключ-значення” завдання контролю цілісності даних повністю лягає на додаток. По-друге, процес створення реляційного сховища включає в себе етап проектування моделі даних. На цій стадії можна оцінити вузькі місця обраної стратегії і спроектувати дійсно надійну і зручну систему. NoSQL рішення не вимагають визначати схему бази даних перед початком роботи. Але без етапу первісного тестування і планування можна в процесі розробки наштовхнутися на непередбачені труднощі, які можуть навіть повністю відсікти варіант роботи з конкретним NoSQL рішенням. А з огляду на описані в попередньому пункти труднощі швидкого переходу з однієї нереляційної бази даних на іншу — ціна помилки стає дуже високою.

Тепер є сенс обговорити іншу важливу особливість NoSQL баз даних — всі вони здебільшого досить молоді. Багато з них поширюються по BSD-подібної ліцензії і підтримуються зусиллями спільноти. У кожної компанії свої вимоги до надійності бази даних, і велика частина NoSQL рішень залишаються непоміченими часто, тому що вони є ще занадто молодими рішеннями. Багато нереляційних баз даних існують лише у вигляді бета-версій, і навіть самі зрілі мають досить малий багаж історій успішного впровадження в порівнянні з реляційними СУБД. Крім ймовірності наявності багів і вразливостей в самому коді нереляційних СУБД, це призводить до інших помилок, деякі компанії обирають рішення, які просто не відповідають їхнім потребам.

Найсильніші сторони NoSQL

Після огляду спірних особливостей більшості NoSQL рішень є сенс розглянути той напрям, в якому ці системи максимально розкривають свій потенціал. Це розподілені системи. Вагомими перевагами при роботі з розподіленими системами мають всі типи нереляційних сховищ, за винятком графових БД — вони за визначенням передбачають велику кількість зв’язків між вузлами даних.

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

Ключові переваги NoSQL баз в розподілених системах полягають в процедурах шарингу і реплікації.

Реплікація — це копіювання даних при їх оновленні на інші сервера. Цей механізм дозволяє домогтися більшої відмовостійкості і масштабованості системи. Прийнято виділяти два види реплікації: master-slave і peer-to-peer.

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

Другий тип peer-to-peer — припускає, що всі вузли рівні в можливості обслуговувати запити на читання і запис. Інформація про оновлення даних передається від сервера до сервера по колу.

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

Соціальні дані

Досить популярним аргументом на стороні рішень є той факт, що соціальні дані не є реляційними і реалізація великих соціальних мереж засобами SQL сховищ пов’язана з певними складнощами. Дійсно, формування стрічки новин для користувача засобами реляційної бази даних являє собою операцію з’єднання декількох таблиць. Пости новинної стрічки, лайки і коментарі, аватари користувачів і безліч інших даних, необхідних для формування стрічки зазвичай зберігаються окремо, тому зведення цих даних воєдино часто проходить не так швидко, як хотілося би. Збереження всієї стрічки користувача у вигляді єдиної ненормалізованих структури виглядає дуже хорошим рішенням. Але реалізовані в даний момент графові NoSQL бази мають проблему з масштабуванням, що не дозволяє використовувати їх для великих соціальних мереж. Крім цього реляційні сховища мають і низку інших переваг, у числі яких надійність, гарантія цілісності інформації і безпеки  даних користувача. При реалізації дійсно складних багатокористувацьких проектів блискавична швидкість і нескінченна масштабованість системи рідко виходять на перший план. В першу чергу компанії прагнуть зробити надійний продукт.

Пік популярності NoSQL рішень був багато в чому пов’язаний з амбітною заявою, що надійшли від соціальної мережі Twitter. Вони бачили певні недоліки роботи з реляційною сховищем MySQL для своїх твітів і виявили бажання перейти на нову NoSQL СУБД Cassandra. Але ця ідея так і не була втілена в життя. Як коментують цей момент самі співробітники Twitter: компанія оцінила свої пріоритети, після чого рішення було визнано занадто ризикованим. З іншого боку, те ж саме NoSQL сховище відмінно прижилося в якості основної бази даних для соціальних мереж Instagram і Facebook, а це вже дуже вагомі історії успіху для всього сімейства NoSQL.

Аналітика даних

У хмарних сховищах і розроблених для них NoSQL рішеннях часто використовується принцип множинної оренди. Він полягає в тому, що велика кількість користувачів одночасно використовує одну і ту ж систему. Щоб запобігти її перевантаження в рішеннях, розрахованих на велику масштабованість, застосовують політику обмеження запитів. Наприклад, в SimpleDB час виконання запиту не може перевищувати 5 секунд, а в Google AppEngine Datastore один запит до бази не дозволяє отримати більше 1000 записів.

Ці обмеження не страшні для простої роботи програми, але значно позначаються на можливостях аналітики даних. Компанії часто отримують вигоду від великих обсягів даних користувача. На основі їх аналізу можна виділяти найбільш популярні продукти, складати “на льоту” списки рекомендацій для конкретних груп користувачів грунтуючись на їх особистих даних або історії. Для багатьох NoSQL рішень подібні функції складно реалізувати або вони є просто неможливі.

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

Підсумки

Різкий стрибок популярності NoSQL баз даних і пов’язані з ним історії використання нереляційних СУБД показали світу IT важливість реалістичної оцінки пріоритетів компанії. Деякі вендори успішно впровадили у себе NoSQL сховища і отримали помітне зниження збитків і підвищення якості їх додатків. Інші зазнали невдачі, пізно зрозумівши, що прийняте рішення їм не підходить. А треті просто залишилися зі своїми технологіями. Реляційні або нереляційні бази даних не єдиний вибір, який належить зробити компанії. Не менш важливим є і вибір між конкретними системами і конкретними стратегіями роботи з ними.

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

Джерело:

https://veesp.com/ru/blog/sql-or-nosql

Related posts

Leave a Comment

Цей сайт використовує Akismet для зменшення спаму. Дізнайтеся, як обробляються ваші дані коментарів.