г до них, однак така стандартизація стане необхідна у міру створення нових високонавантажених систем і підвищення вимог до швидкості обробки і вартості розробки. Наявність єдиних стандартів полегшить використання декількох NoSQL СУБД в одному проекті, спростить інтеграцію СУБД між собою, прискорить міграцію на нові СУБД, зробить можливим створення універсальних інструментальних засобів NoSQL, дозволить заздалегідь здійснювати підготовку фахівців з NoSQL і т. д.
У 2011 році був зроблений перший крок у напрямку стандартизації - анонсований мова запитів UnQL (Unstructured Query Language) для роботи з неструктурованою інформацією. Для зручності прикладних розробників синтаксис і семантика мови багато в чому схожі з SQL, що цілком природно - завдяки підтримці UnQL кожна NoSQL-СУБД може стати гнучким, зручним і легко використовуваним інструментом, і вона як і раніше буде грунтуватися на власних технічних рішеннях, дають перевагу у будь-яких умовах експлуатації.
Як приклад можна вказати систему для зберігання пар «ключ - значення». Якщо все СУБД підтримують UnQL, то прикладної розробник може підібрати оптимальну, практично не міняючи коду програми. Наприклад, якщо необхідна організація кешування, то краще використовувати СУБД, орієнтовану на роботу в пам'яті (наприклад, membase). Якщо необхідна робота з рідко змінюються даними, то має сенс вибрати СУБД, призначену для роботи саме в таких умовах (наприклад, CDB). Якщо крім пошуку необхідне сортування ключів, то підійде система, заснована на B-деревах (наприклад, BerkleyDB).
Що краще?
Реляційні СУБД не поспішають миритися зі своїми недоліками і підтримують всі нові типи даних, що використовуються в системах NoSQL. Найпростіші приклади такого розвитку (підтримка типів BLOB і повнотекстового пошуку) вже згадувалися, а більш складний приклад - підтримка XML-документів і XPath-запитів. Ця функціональність ключова для спеціалізованих СУБД (BaseX, eXist), орієнтованих на роботу з XML, але вона ж майже повністю присутній у деяких реляційних СУБД (наприклад, в Oracle).
Таким чином, SQL і NoSQL рухаються назустріч один одному, а з часом можуть злитися в єдиний підхід SQL + NoSQL до розробки СУБД. Виникає питання: що краще використовувати - NoSQL або SQL? Широко поширена і добре вивчена реляційна СУБД дає масу додаткових переваг: інтеграція з вже існуючими рішеннями на базі реляційних СУБД, відмовостійкість, наявність більш багатого інструментарію і т. д. Зараз спостерігається тенденція застосування NoSQL замість SQL, але не виключено, що в міру розвитку SQL почнеться зворотний рух. З часом, чим ближче будуть ставати SQL і NoSQL, тим більше буде «метань» від одного підходу до іншого.
При об'єднанні SQL і NoSQL в єдине рішення через різноманіття використовуваних методів зберігання інформації СУБД може перетворитися на величезний чорний ящик зі складними і розгалуженими настройками, що сильно ускладнить роботу з нею. Схожа ситуація вже відбувалася з деякими мовами програмування (наприклад, Алгол - 68, PL / 1), коли їх семантика виявилася сильно перевантажена і замість зручного інструменту розробники отримали погано керованого «монстра». Крім того, якщо буде розроблений стандарт на системи SQL + NoSQL, то він може виявитися занадто складним і перевантаженим.
Рішення полягає у коригуванні самої концепції СУБД, що припускає, що такі системи повинні являти собою не монолітний сервер з ко...
