Чи недоцільно використання баз даних NoSQL для великих наборів даних, де потрібно здійснювати пошук за вмістом?

Я вже тиждень дізнаюся про бази даних NoSQL.

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

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

Бази даних NoSQL - це (найчастіше) сховища ключових значень.

Звичайно, можна зберігати все у сховищі ключових значень (кодуючи дані в JSON, XML, будь-що інше), але проблема, яку я бачу, полягає в тому, що вам потрібно отримати деяку кількість даних, що відповідає певному критерію, у багатьох випадки використання. У базі даних NoSQL у вас є лише один критерій, за яким можна ефективно шукати - ключ. Реляційні бази даних оптимізовані для ефективного пошуку будь-якого значення в рядку даних.

Тож бази даних NoSQL насправді не є вибором для збереження даних, які потребують пошуку за їх вмістом. Або я щось неправильно зрозумів?

Приклад:

Потрібно зберігати дані користувачів для веб-магазину.

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

У базі даних NoSQL ви зберігаєте кожного користувача зі своїм ідентифікатором як ключовим, а всі його дані (закодовані в JSON тощо) як значення.

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

Я не кажу, що це неможливо , але він стає набагато складнішим, і я думаю, що це не так ефективно, якщо ви хочете шукати в даних записів NoSQL.

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

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

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

У базі даних NoSQL у вас є лише один критерій, за яким можна ефективно шукати - ключ.

Це явно не вірно.

Наприклад, MongoDB підтримує індекси. (з https://docs.mongodb.org/v3.0/core/indexes-introduction/ )

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

Індекси - це спеціальні структури даних [1], які зберігають невелику частину набору даних колекції у легкій для проходження формі. Індекс зберігає значення певного поля або набору полів, упорядкованих за значенням поля. Впорядкування записів індексу підтримує ефективні збіги рівності та операції запитів на основі діапазону. Крім того, MongoDB може повернути відсортовані результати, використовуючи впорядкування в індексі.

Як і couchbase (від http://docs.couchbase.com/admin/admin/Views/views-intro.html )

Перегляди Couchbase дозволяють індексувати та запитувати дані.

Перегляд створює індекс даних відповідно до визначеного формату та структури. Вид складається з конкретних полів та інформації, витягнутої з об'єктів Couchbase.

Насправді все, що називає себе базою даних NoSQL, а не сховищем ключових значень, повинно реально підтримувати певні схеми індексації.

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

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

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

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

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

Різниця? Двигуни SQL мали концепцію індексації вбудованої таблиці. Це означає, що вам доведеться зробити менше роботи (все, що вам потрібно було зробити, - додати індекс до таблиці). Однак це також означає, що ви мали менший контроль. У більшості випадків ця втрата контролю є прийнятною в обмін на SQL-механізм, який виконує роботу за вас. Однак у масових наборах даних вам може знадобитися інша модель узгодженості, ніж типова модель SQL ACID. Ви можете використовувати модель BASE, яка підтримує можливу послідовність. Це може бути дуже складно в SQL, тому що двигун SQL робить для вас роботу, тому це потрібно робити за правилами двигуна SQL. У NoSQL ці шари, як правило, піддаються впливу, що дозволяє вам зламати їх.

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

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

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

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

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

Ці цілі часто конфліктують між собою. Дуже багато користувачів твіттера слідкують за людьми з усього світу. Чи слід географічно оптимізувати базу даних Twitter, щоб читати твіти або писати твіти?

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

Бази даних NoSQL мають дуже мало спільного з " Немає SQL".

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

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

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

Наприклад:

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

Як справжній приклад, Amazon швидше покаже мені застарілий опис книги, ніж затримати показ веб-сторінки, дочекавшись 106 комп'ютерів, щоб підтвердити, що правильний замок знято.

Тому .....

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

Але як тільки вам доведеться задуматися про використання декількох реляційних баз даних або розбиття транзакцій, щоб уникнути помилок блокування, ви йдете по дорозі, щоб впоратися з типом проблем, які виникають при використанні баз даних "NoSQL".

Оскільки бази даних "NoSQL" не приховують цих проблем, вони можуть стати найкращим варіантом, коли ви масштабуєте систему. Але пам’ятайте, що Stackoverflow все ще використовує реляційну базу даних для зберігання всіх своїх даних з обмеженим використанням NoSQL в шарі кешування - тому вам потрібно бути ДУЖЕ великим, перш ніж ви змушені використовувати NoSQL для зберігання своїх даних.

Реляційні бази даних оптимізовані для ефективного пошуку будь-яких значень у даних.

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

Відповідей уже багато, але я просто хотів додати своє резюме.

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

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

Я використовую couchdb вже два роки. В основному використовується для управління вмістом та конфігурацією.

Адже ієрархічні стосунки набагато простіше керувати, коли можна їх візуалізувати. Для даних, що здебільшого читають, редагувати JSON простіше, ніж у багатьох випадках писати операцію UPDATE. Фактично не потрібно програмісту редагувати JSON. І SQL дає вам рядки та стовпці, які потім доведеться зіставити у якусь структуру об'єкта.

Ви також отримуєте підвищення продуктивності, оскільки ви не приєднуєтесь до 10-20 таблиць у складних запитах. Перегляди Couchdb дуже швидкі, тому що javascript, на якому вони засновані, не виконується під час запитів.

Більшість програмістів розуміють Javascript, а більшість програмістів періодично борються зі SQL.

У Couchdb погляд можна розглядати як абстрактний документ JSON. Як структуруються дані подання, залежить від вас (вас не обмежує оригінальна ієрархія).

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

Зауважте, що немає чіткої «нормалізації», яку можна застосувати (хоча уникнення дублювання даних є гідною метою), і існує по суті та «оптимістична» стратегія оновлення, схожа на оптимістичне блокування.