Вошла ли борьба между старым и новым в мире СУБД, между SQL и NoSQL, в определенные рамки, остался ли, наконец, позади ее начальный этап? Есть признаки, указывающие, что это так, и это хорошо для отрасли.

В ходе недавней избирательной кампании в США мы могли сделать обоснованный вывод, что общество поляризовано. Во всяком случае, в Соединенных Штатах. Это вызывает сожаление. А в области технологий враждебность еще менее оправданна.

В мире СУБД не должно быть деления на партии, но этот мир не должен быть и монолитным. Интернет и создание систем для него учат нас, что организации и даже их подразделения предъявляют свои требования.

В конечном итоге, различные лагеря должны смягчить свои позиции, согласовать их и, в сущности, объединиться. У них могут быть и действительно имеются свои сильные стороны. Но им следует составить единый спектр, а не создавать фракции.

И, да, я действительно говорю сейчас о СУБД. А именно, о так называемых NoSQL- и реляционных СУБД (РСУБД).

Что случилось?

Почти восемь лет назад появился термин NoSQL, описывающий новый класс СУБД. Относящиеся к этой категории продукты и проекты с открытым исходным кодом освободили пользователей от систем, которые не могли обеспечить разнообразие схем таблиц, для которых кластеризованная, географически распределенная инфраструктура была основным препятствием, которые использовали парадигмы представления данных, отличающиеся от используемых в большинстве языков программирования, и которые блокировали операции, когда в базу вводились новые данные.

Но с обретением этой свободы были утрачены многие особенности РСУБД, имевшие принципиальное значение для большинства производственных систем и связанные далеко не только с акцентированием языка SQL. К таким принципиальным особенностям, которыми пришлось пожертвовать, относятся отличные от первичного ключа индексы колонок, явные объединения таблиц и так называемые гарантии ACID — неразделимость обновлений части базы данных и компенсирующих изменений в других ее частях (подобно кредиту и соответствующему дебиту).

Сближение

Процесс примирения этих двух архитектур управления базами данных, наконец, в полном разгаре. Важными свидетельствами этого стали сделанное на прошлой неделе объявление MongoDB о предстоящем релизе 3.4 ее одноименной СУБД (канонического NoSQL-хранилища документов), а также появление три недели назад бета-релиза 3.1 основной графо-ориентированной СУБД Neo4j. Накопились и другие изменения, каждое из которых является знаком примирения и служит прекращению войны СУБД.

Neo4j смягчила воинственный отказ NoSQL от гарантий ACID и заменила его столь любимой сторонниками NoSQL «согласованностью в конечном счете». В Neo4j 3.1 вместо этого предлагается нечто под названием «причинная согласованность». Заметьте, причинная (causal), а не случайная (casual). Такая модель делает операции более похожими на ACID и позволяет разработчикам указывать требуемый уровень согласованности баз данных, когда чтение данных происходит сразу после их записи.

Нео-ретро

В конечном счете, все серверы кластера получат обновления, и чтение затронутых ими данных будет происходить очень быстро. Но как быть с запросами на чтение этих данных в процессе обновления? Используя версию 3.1, разработчики Neo4j могут задавать в настройках, должен ли сначала этот процесс полностью завершиться или чтение должно происходить сразу.

Но ради ускорения (balance and nuance) разработчики могу также разрешить совершение транзакции, когда изменения произведены на «кворуме» серверов, один из которых обслужит запрос на чтение. Каждый вариант предполагает различные компромиссы, касающиеся производительности и целостности. Так и должно быть при наличии целого спектра требований.

Mongo: и то, и это

MongoDB 3.4 является уже не просто хранилищем документов. Иными словами, эта СУБД выходит за рамки хранения и обслуживания данных, записанных в нотации JavaScript Object Notation (JSON). Теперь MongoDB также поддерживает обработку графов, что до сих пор было самостоятельным направлением NoSQL. В ней появилась также технология фасеточного поиска. Имея сходство с подходом, используемым поисковыми машинами в Интернете и на предприятиях, фасеточная навигация позволяет искать или фильтровать данные по атрибутам. Такая парадигма знакома использующим технологию бизнес-интеллекта OLAP.

И если вам недостаточно этого свидетельства примирения, то MongoDB 3.4 будет самым торжественным образом поддерживать интерфейс запросов на языке SQL. Это, в свою очередь, позволит подключать к MongoDB практически все основные пакеты бизнес-интеллекта в качестве источников данных без использования специальных драйверов. Чему особенно будет способствовать включенный в MongoDB диалект SQL, видимо, совместимый с диалектом РСУБД с открытым исходным кодом MySQL.

Под влиянием Редмонда?

Чем особенно интересны эти изменения? Тем, что они появились вслед за почти идентичными компромиссами со стороны Microsoft, сторонницы РСУБД. Несмотря на наличие у нее SQL Server, Microsoft представила некоторое время назад собственную NoSQL СУБД под названием DocumentDB. Как показывает название продукта, он предназначен для хранения документов.

Как бы то ни было, Microsoft придала DocumentDB с момента запуска две не характерные для данной категории особенности (которые теперь могут показаться знакомыми): интерфейс запросов на языке SQL и настраиваемые уровни целостности базы данных. Позднее Microsoft добавила совместимый с MongoDB API-интерфейс. В результате оба продукта предоставляют теперь возможность составлять запросы двух видов. А после того, как MongoDB анонсировала свой облачный сервис Atlas, эти две платформы идут голова в голову.

Если вам этого недостаточно, вспомните, что новейшая версия SQL Server, созданной почти 25 лет назад РСУБД Microsoft, теперь может осуществлять хранение и поиск данных в том же формате JSON, который является естественным для DocumentDB и MongoDB. Это не означает, будто MS SQL (как часто именуют SQL Server в кругах не работающих в Microsoft разработчиков) относится теперь к категории NoSQL. А означает это размывание границ между категориями. Их названия все меньше соответствуют действительности.

Влияние на состояние отрасли

Это хорошо. Потому что, в конечном счете, ради развития отрасли необходимо прекратить междоусобицу и совместными усилиями двигаться вперед.

Доминирование одной идеологии не сулит ничего хорошего. Сторонникам противостоящих подходов стоит организоваться и начать честную борьбу за изменения. Но в итоге каждая сторона сможет чему-то научиться у другой, что сделает их обеих более информированными, более разносторонними и менее враждебными. От этого выиграют и клиенты, и производители. Они получат возможность двигаться вперед и решать новые проблемы.