Заказчики все чаще требуют, чтобы их СУБД решали различные задачи. Развитие многомодельных СУБД, предоставляющих разработчикам различные возможности посредством API-интерфейсов, является новым подтверждением этой тенденции, пишет Тони Баер из консалтинговой компании Ovum на портале ZDNet.
Базы данных традиционно были весьма специализированным способами хранения данных, предназначенными для специфических задач, и до недавнего времени они становились все более специализированными. Помните хранилища данных? Кто-то заметил, что они являются «исправлениями» недостатков транзакционных СУБД при работе с большим объемом данных — их анализе, обработке запросов и подготовке отчетов. Но по общему мнению, после 2000 г. реляционные SQL-СУБД стали корпоративным стандартом де-факто, пока не были погребены под трафиком, создаваемым интернет-приложениями. В результате появились СУБД NoSQL для обработки операционных данных (например, онлайновых профилей пользователей или каталогов продукции) и хранилища больших данных вроде Hadoop для работы со многими терабайтами и петабайтами данных.
Хорошая новость в том, что платформы данных были способны решать гораздо более широкий круг задач, плохая — в том, что все эти предназначенные для конкретных целей хранилища создавали новые островки данных. То же можно сказать и об озерах данных.
Реакция на распространение островков данных вызвала повышение универсальности СУБД. Баер вспоминает о приглашении выступить в 2014 г. на одной большой конференции по проблеме данных. К этому выступлению была подготовлена презентация, посвященная новой тогда тенденции конвергенции баз данных. В транзакционные СУБД добавлялись предназначенные для аналитики столбцы, хранящиеся в оперативной памяти. В SQL-СУБД появилась поддержка запросов к документам JSON (и наоборот). Стал возможен доступ к Hadoop посредством интерактивных запросов на языке SQL. Некоторые аналитические фирмы даже разрабатывали новую категорию «гибридных» СУБД — охватывающих аналитику транзакционных СУБД.
Уже тогда Баеру казалось само собой разумеющимся, что базы данных перекрывают друг друга. По его мнению, это явление лучше было назвать не конвергенцией, а именно взаимным перекрытием. Установка DB2 или Oracle с поддержкой JSON не обязательно должна приводить к удалению MongoDB. Точно также инсталляция Couchbase с языком запросов N1QL не обязательно должна заменять MySQL или Oracle. Если заказчик собирается сменить СУБД (скажем, перейти с SQL на NoSQL), то, вероятно, потому что ему потребовались более гибкие модели данных. А использование платформы данных с расширенными возможностями, такой SQL СУБД с расширением JSON, больше подходит для пограничных случаев, например, когда требуется дополнить записи транзакций клиентов данными из журнала, показывающими их навигацию по сайту компании.
Однако за последний год произошел всплеск интереса к мультимодельным СУБД. Типичным примером является Azure Cosmos DB с ее разнообразными API-интерфейсами. Хотите документную СУБД? У вас есть выбор. Можете использовать ее собственный API-интерфейс (первоначально разработанный для DocumentDB, предшественницы Cosmos DB) или разновидность MongoDB с BSON. Хотите хранилище «ключ-значение»? Используйте Azure Table Storage API. Хотите граф или SQL? Имеется соответствующий API-интерфейс.
Хотя многомодельность является не единственным достоинством Cosmos DB (глобальная распределенная масштабируемость и конфигурируемые модели согласованности, безусловно, играют свою роль), эта платформа менее чем за год принесла доход в размере свыше 100 млн. долл. Почему она пользуется таким спросом?
По словам Риммы Неме, менеджера группы продуктов Cosmos DB, чаще всего многомодельность используется в сценариях, которые традиционно требовали нескольких СУБД. Хорошим примером может служить электронная коммерция. Здесь записи о транзакциях клиентов моделируются как реляционные, навигация по веб-сайту лучше всего может быть представлена в виде документов JSON, а сегментация с целью сделать следующее по списку лучшее предложение — как графы поведения клиента. Не удивительно, что наиболее важные отзывы клиентов о Cosmos DB относятся к электронной коммерции.
Новые подтверждения отмеченной тенденции поступают из мира открытого ПО. OrientDB предоставляет графовую, документную, ключ-значение, реактивную, объектно-ориентированную и геопространственную модели на одном движке. Yugabyte только что выпустила многомодельную СУБД. Начало довольно скромное, но планы грандиозные. Версия 1.0, спроектированная как распределенная транзакционная СУБД, является незавершенной. Пока она поддерживает API-интерфейсы Apache Cassandra и Redis, а также модель изоляции моментальных снимков ACID. Когда компания завершит работу над своим шедевром, появятся API-интерфейсы для графов, полнотекстового поиска и хранения объектов (облачно ориентированного). Для ACID будет вариант упорядочиваемой согласованности транзакций. Говоря об API-интерфейсах, следует отметить, что платформа Amazon Neptune разрушает шаблонное представление о графовой СУБД, предоставляя оба варианта графа посредством поддержки графов Resource Description Framework и свойств графа через API-интерфейсы.
Появление СУБД, использующих API-интерфейсы для изменения собственной оболочки, служит новым подтверждением, что предприятия хотят преодолеть изолированность своих СУБД.
