Майкл Стоунбрейкер: «Всё новое — это хорошо забытое старое. Продолжение»

От редакции: Майкл Стоунбрейкер — один из самых известных в IT мире ученых и отец-основатель Postgres. В соавторстве с Энрю Павло недавно опубликовал большой обзор всех актуальных технологий систем управления базами данных. В этом материале — подробно обо всем, что произошло в мире баз данных за последнее время, а также прогнозы. Мы посчитали что нельзя лишать нашу аудиторию возможности ознакомиться с этим обзором, поэтому подготовили данный перевод.

---

Аннотация

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

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

Введение

В 2005 году один из нас написал для Red Book главу под названием What Goes Around Comes Around («Всё новое — это хорошо забытое старое»). В ней рассматривались основные этапы развития моделирования данных, начиная с 1960-х годов:

• Иерархическое (например, IMS): конец 1960-х и 1970-е годы

• Сетевое (например, CODASYL): 1970-е годы

• Реляционное: 1970-е и начало 1980-х годов

• Сущность — связь: 1970-е годы

• Расширенное реляционное: 1980-е годы

• Семантическое: конец 1970-х и 1980-е годы

• Объектно‑ориентированное: конец 1980-х и начало 1990-х годов

• Объектно‑реляционное: конец 1980-х и начало 1990-х годов

• Слабоструктурированное (например, XML): конец 1990-х и 2000-е годы

Мы пришли к выводу, что реляционная модель с расширяемой системой типов (то есть объектно‑реляционная) доминировала на рынке над всеми остальными. Хотя многие из нереляционных СУБД образца 2005 года до сих пор существуют, производители лишь поддерживают их, но никто не создаёт на них новые приложения. Это больше свидетельствует о «липкости» данных, а не о продолжающемся могуществе этих систем. Другими словами, многие базы данных IBM IMS существуют только потому, что их дорого и рискованно переводить на современные СУБД. Но ни один стартап добровольно не выберет IMS для создания нового приложения.

С 2005 года в мире баз данных произошло много событий. За это время СУБД распространились на область обработки бизнес‑данных и теперь используются почти для любых данных. Это привело к эре Big Data в начале 2010-х и текущему тренду интеграции машинного обучения (ML) с технологией СУБД.

В этой статье проанализируем, какие изменения произошли за последние 20 лет в области моделей данных и языков запросов в базах данных. Мы коснемся следующих областей:

1. Системы MapReduce

2. Хранилища «ключ — значение»

3. Документоориентированные базы данных

4. Базы данных типа «Семейство столбцов»

5. Текстовые поисковые движки

6. Базы данных массивов

7. Векторные базы данных

8. Графовые базы данных

По нашим данным, большинство систем, отличных от SQL или РM, не доминировали на рынке СУБД и зачастую обслуживают только нишевые рынки. Многие системы, которые помпезно начинали с отказа от РM (вспомните NoSQL), теперь предоставляют интерфейс, похожий на SQL для РM‑баз данных. Такие системы теперь находятся на пути к слиянию с реляционными СУБД. Тем временем SQL аккумулировал лучшие идеи языков запросов, чтобы расширить поддержку современных приложений и оставаться актуальным.

Хотя основные принципы РM не слишком изменились, в реализациях РМ‑систем произошли существенные перемены. Во второй части этой статьи мы обсудим достижения в архитектурах СУБД, касающиеся современных приложений и оборудования:

1. Колоночные системы

2. Облачные базы данных

3. Озера данных / Lakehouses

4. Системы NewSQL

5. Аппаратные ускорители

6. Блокчейн — базы данных

Некоторые из них значительно изменились в реализациях СУБД, а другие вышли в тренд из‑за ложных предпосылок.

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

Модели данных и языки запросов

Разделим исследования и разработки в области моделей данных и языков запросов для баз данных на восемь категорий.

Системы MapReduce

Google создал инфраструктуру MapReduce (MR) в 2003 году как точечное решение для обработки результатов своего периодического обхода интернета. В то время у Google было мало опыта в технологиях СУБД, и в компании разработали MR для удовлетворения своих потребностей в обходе. В терминах баз данных, Map — это функция, определенная пользователем (user-defined function, UDF), которая выполняет вычисления и/или фильтрацию, в то время как Reduce — операция GROUP BY. В первом приближении MR выполняет один запрос:

SELECT map() FROM crawl_table GROUP BY reduce()

Подход Google к MR не предписывал конкретную модель данных или язык запросов. Вместо этого функции Map и Reduce, написанные в процедурной программе MR, парсили и расшифровывали содержимое файлов данных.

В конце 2000-х годов другие компании заинтересовались системами на основе MR. В 2005-м Yahoo! разработала открытую версию MR и назвала ее Hadoop. Она работала на вершине распределенной файловой системы HDFS, которая была клоном Google File System. Появилось несколько стартапов для поддержки Hadoop на коммерческом рынке. Мы будем обозначать MR реализацию Google, а Hadoop   —опенсорсную версию. Они функционально схожи.

Споры о ценности Hadoop по сравнению с реляционными СУБД для аналитических нагрузок (OLAP) привели к исследованию 2009 года, которое показало, что СУБД для хранилищ данных превосходят Hadoop. Это породило статьи, вокруг которых разгорелись споры между Google и СУБД-сообществом. Google утверждал, что при тщательном проектировании система MR превзойдет СУБД и пользователю не придется загружать данные со схемой перед запуском запросов. Таким образом, MR лучше подходит для разовых задач, таких как обработка текста и операции ETL. СУБД-cообщество утверждало, что дизайн MR вызывает проблемы с производительностью, которые уже  решены в существующих параллельных СУБД. Кроме того, использование более высокоуровневых языков (SQL), работающих с секционированными таблицами, доказало свою состоятельность в качестве модели программирования.

Многие обсуждения в двух статьях касались вопросов реализации (например, индексирование, парсинг, push- vs. pull-обработка запросов, восстановление после сбоев). После чтения статей напрашивается разумный вывод, что оба типа систем имеют право на существование. Однако два события в мире технологий сделали этот спор неактуальным.

Первым событием стало крушение рынка технологий и услуг Hadoop в 2010-х. Многие корпорации потратили большие деньги на кластеры Hadoop, чтобы разочароваться в нём. Разработчикам было сложно приспособить свои приложения к ограниченной парадигме MR/Hadoop. Были попытки предоставить интерфейс SQL и РM поверх Hadoop, самая заметная среди них Hive от Meta.

Следующее событие произошло через восемь месяцев после статьи в CACM, когда Google объявил, что переводит обработку индексации сайтов с MR на BigTable. Причина заключалась в том, что Google нужно было интерактивно обновлять свою базу данных индексации сайтов в реальном времени, но MR была пакетной системой. Наконец, в 2014 году Google объявил, что MR больше нет места в их технологическом стеке и избавился от него.

Первое событие оставило трех ведущих поставщиков Hadoop (Cloudera, Hortonworks, MapR) без жизнеспособного продукта для продажи. Cloudera переименовала Hadoop, чтобы это имя обозначало весь стек (приложение, Hadoop, HDFS), а дальше создала реляционную СУБД Impala поверх HDFS, но не используя Hadoop. В компании  поняли, что Hadoop не годится в качестве внутреннего интерфейса в SQL-СУБД, и исключили его из своего стека, создав программное обеспечение напрямую на HDFS. В аналогичном ключе MapR создал Drill непосредственно на HDFS, а Meta создала Presto, чтобы заменить Hive.

Обсуждение: Недостатки MR были столь значительными, что его не удалось спасти, несмотря на принятие и энтузиазм со стороны сообщества разработчиков. Hadoop умер примерно десятилетие назад, оставив корпорациям в наследство кластеры HDFS и ряд компаний, стремящихся заработать на них. Сейчас HDFS потерял свою привлекательность, поскольку компании осознали, что существуют лучшие альтернативы распределенному хранению. Тем временем распределенные реляционные СУБД процветают, особенно в облаке.

Некоторые аспекты реализации систем MR, связанные с масштабируемостью, эластичностью и отказоустойчивостью, перешли в распределенные реляционные СУБД. MR также привел к возрождению архитектур с общей дисковой системой с раздельным хранением, что впоследствии дало начало открытым файловым форматам и озерам данных. Ограничения Hadoop открыли двери для других платформ обработки данных — Spark и Flink. Обе системы начинали как лучшие реализации MR с процедурными API, но с тех пор добавили поддержку SQL.

Хранилища «ключ – значение»

Модель данных «ключ – значение» (key – value, KV) — самая простая из возможных. Она представляет следующую бинарную связь (key, value).

СУБД KV представляет собой коллекцию данных в виде ассоциативного массива, который отображает ключ в значение. Значение — это обычно нетипизированный массив байтов (blob), и СУБД не знает его содержимого. Поддерживает схему и парсит значения приложение. Большинство СУБД KV предоставляют только get/set/delete одного значения.

В 2000-х несколько новых интернет-компаний создали свои собственные распределенные хранилища KV без общей памяти для узкоспециализированных приложений, например, для кэширования и хранения данных сессий. Memcached — самый известный пример такого подхода для кэширования. Redis позиционируется как замена Memcached и предлагает более надежный API для запросов с поддержкой контрольных точек. Для более устойчивых данных приложений Amazon в 2007 году создал хранилище KV Dynamo. Такие системы предлагают более высокую и предсказуемую по сравнению с реляционной СУБД производительность в обмен на ограниченную функциональность.

Вторая категория СУБД KV — встроенные менеджеры хранения, предназначенные для работы в том же адресном пространстве, что и приложение верхнего уровня. Одной из первых автономных встроенных СУБД KV была BerkeleyDB, созданная в начале 1990-х. Среди последних заметных примеров можно отметить LevelDB от Google, которую Meta позже форкнула в RocksDB.

Обсуждение: Хранилища «ключ – значение» предоставляют разработчикам быстрый способ хранения данных «из коробки» по сравнению с более трудоемким процессом настройки таблицы в реляционной СУБД. Конечно, опасно использовать хранилище KV в сложных приложениях, которые требуют больше, чем просто бинарную связь. Если приложению нужно несколько полей в записи, то хранилища KV, вероятно, будут плохой идеей. Во-первых, приложению придется парсить поля записи, а во-вторых здесь не будет вторичных индексов для получения других полей по значению. Разработчики должны реализовать операции join или multi-get в своем приложении.

Для решения этих проблем появилось несколько систем, которые начинали как хранилище KV, а затем перешли к более функционально насыщенному хранению записей. Такие системы заменяют непрозрачное значение на слабоструктурированное, например, JSON-документ. Примеры этого перехода включают DynamoDB от Amazon и Aerospike. Перепроектировать хранилище KV для поддержки сложной модели данных непросто, тогда как реляционные СУБД легко эмулируют хранилища KV без каких-либо изменений. Если приложению нужна встроенная СУБД, доступны полнофункциональные варианты, включая SQLite и DuckDB. Следовательно, реляционная СУБД может быть лучшим выбором даже для простых приложений, поскольку они предлагают путь к дальнейшему развитию в случае увеличения сложности приложения.

Новая архитектурная тенденция последних 20 лет заключается в использовании встроенных движков KV в качестве основного механизма хранения для полнофункциональных СУБД. Ранее создание новой СУБД требовало от инженеров разработки кастомного движка, который был бы нативно интегрирован в СУБД. MySQL стала первой СУБД, которая предоставила API, позволяющий разработчикам заменять ее стандартный движок KV. Этот API позволил Meta создать RocksDB для замены InnoDB в их огромном парке баз данных MySQL. Аналогично MongoDB отказалась от своего неудачного движка хранения на основе MMAP в пользу хранилища KV WiredTiger в 2014 году. За счет существующего KV-движка разработчики могут быстрее создать новую СУБД.

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

Модель данных документов представляет базу данных как коллекцию объектов-записей. Каждый документ содержит иерархию пар поле-значение, где каждое поле идентифицируется по имени, а значение поля может быть скаляром, массивом значений или другим документом. Пример JSON ниже показывает документ клиента, содержащий вложенный список записей заказов с соответствующими элементами.

{   "name": "First Last",   "orders": [     { "id": 123, "items": [...] },     { "id": 456, "items": [...] }   ] }

Модели данных документов активно разрабатывались в течение нескольких десятилетий. Это привело к появлению таких форматов данных, как SGML и XML. Несмотря на ажиотаж вокруг XML-баз данных в конце 1990-х, они не заменили реляционные СУБД, как мы и предсказывали в 2005 году. JSON с тех пор обогнал XML и стал стандартом обмена данными для веб-приложений. Популярность JavaScript среди разработчиков и сопутствующее распространение JSON привели к созданию нескольких систем, ориентированных на документы, которые нативно хранили JSON в 2000-х.

Неспособность OLTP-реляционных СУБД масштабироваться в 2000-х годах привела к появлению множества документных СУБД, которые продвигались под лозунгом NoSQL. Эти системы предлагали два маркетинговых мессаджа, которые находили отклик у разработчиков. Во-первых, SQL и join’ы медленные, и следует использовать более быстрый интерфейс нижнего уровня, работающий с одной записью за раз. Во-вторых, ACID-транзакции не нужны для современных приложений, поэтому СУБД должна предоставлять более слабую их концепцию (например, BASE).

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

Обсуждение: Документоориентированные СУБД  — по сути то же самое, что и объектно-ориентированные СУБД из 1980-х и XML-СУБД конца 1990-х. Сторонники этих СУБД  приводят те же аргументы, что и их OO/XML-предшественники: хранение данных в виде документов устраняет несоответствие между тем, как объектно-ориентированный код приложения взаимодействует с данными, и как реляционные базы данных их хранят. Они также утверждают, что денормализация записей во вложенные структуры лучше с точки зрения производительности, так как устраняет необходимость отправки множества запросов для получения данных, связанных с заданным объектом (т. н. проблема N+1 в ORM). Проблемы с денормализацией / предварительными join’ами восходят к 1970-м: 

1. Если join не является отношением один ко многим, то данные будут дублироваться.

2. Предварительные join не всегда быстрее, чем обычные.

3. Отсутствует независимость данных.

Несмотря на серьезные протесты против SQL, к концу 2010-х почти каждая NoSQL-СУБД добавила интерфейс SQL. Знаковыми примерами являются PartiQL в DynamoDB, CQL в Cassandra, AQL в Aerospike и SQL++ в Couchbase. Дольше других продержалась MongoDB, которая добавила SQL для своего сервиса Atlas в 2021 году. Вместо поддержки стандарта SQL для операций DDL и DML вендоры NoSQL заявляют, что поддерживают собственные проприетарные языки запросов, основанные или вдохновленные SQL. Для большинства приложений эти различия не имеют значения. Любые языковые различия между SQL и его производными в NoSQL в основном связаны с расширениями для поддержки JSON и сервисными операциями.

Многие из оставшихся NoSQL-СУБД также добавили сильно согласованные (ACID) транзакции. Таким образом, мессадж NoSQL изменился с «Не используйте SQL — он слишком медленный!» на «Не только SQL» (т. е. SQL подходит для некоторых задач).

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

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

Базы данных типа «Семейство столбцов»

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

User1000 → { "name": "Alice", "accounts": [ 123, 456 ], "email": "xxx@xxx.edu" } User1001 → { "name": "Bob", "email": [ "yyy@yyy.org", "zzz@zzz.com" ] }

Первую СУБД по модели column-family — BigTable  — разработали в Google в 2004 году. Вместо SQL и появляющегося колоночного хранилища Google использовал эту модель данных с процедурными клиентскими API. Другие системы приняли модель column-family, пытались скопировать уникальную реализацию Google. Самые известные — Cassandra и HBase. Они скопировали и ограничения BigTable, в том числе отсутствие join’ов и вторичных индексов.

Обсуждение: Все наши комментарии из раздела 2.3 о модели данных документов применимы и здесь. В начале 2010-х Google построил реляционные СУБД на основе BigTable, включая MegaStore и первую версию Spanner. С тех пор Google переписал Spanner, убрав остатки BigTable, и теперь это основная база данных для многих внутренних приложений компании. Несколько NoSQL-СУБД отказались от своих проприетарных API в пользу SQL, но при этом сохранили нереляционные архитектуры. Cassandra заменила свой Thrift-API на язык CQL, похожий на SQL, а HBase теперь рекомендует использовать Phoenix SQL-frontend. Google по-прежнему предлагает BigTable как облачный сервис, но модель column-family является единственным исключением с теми же недостатками, что и у NoSQL СУБД.

Текстовые поисковые движки

Текстовые поисковые движки существуют давно, а основополагающей для них стала система SMART, которая появилась в 1960-х годах. SMART заложила основы информационного поиска и векторной модели пространства, почти универсальных в современных поисковых системах. Она рассматривала документы как «мешки слов» и создавала полнотекстовые (или инвертированные) индексы на основе этих токенов для поддержки запросов по их содержимому. Система также учитывала служебные слова (например, «the», «a»), синонимы (например, «The Big Apple» как синоним «New York City»), значимые ключевые слова и расстояние (например, «drought» часто появляется рядом с «climate change»).

Современные ведущие текстовые поисковые системы — Elasticsearch и Solr — используют в качестве внутренней поисковой библиотеки Lucene. Они хорошо поддерживают хранение и индексирование текстовых данных, но почти не предоставляют возможностей для транзакций. Это ограничение означает, что в случае повреждения данных СУБД должна полностью восстанавливать индекс документа, что приводит к значительным простоям.

Все ведущие реляционные СУБД поддерживают полнотекстовые поисковые индексы, включая Oracle, Microsoft SQL Server, MySQL и PostgreSQL. Их поисковые функции недавно улучшились и в целом соответствуют специализированным системам, упомянутым выше. Они также имеют преимущество встроенной поддержки транзакций. Однако их интеграция поисковых операций в SQL часто неудобна и отличается в различных СУБД.

Обсуждение: Текстовые данные по своей природе неструктурированы, что означает отсутствие модели данных. СУБД стремится извлечь структуру (например, метаданные, индексы) из текста, чтобы избежать последовательного поиска иголки в стоге сена. Управлять текстовыми данными в приложении можно тремя способами. Во-первых, можно использовать несколько систем, таких как Elasticsearch для текста и реляционную СУБД для хранения метаинфориации и атрибутов текста. Этот подход позволяет использовать лучшие в своем классе системы, но требует дополнительной ETL-обработки для передачи данных из операционной СУБД в текстовую СУБД и переработки приложений для маршрутизации запросов к нужным СУБД в зависимости от их потребностей. Альтернатива — реляционная СУБД с хорошими возможностями интеграции полнотекстового поиска, но с различающимися API в SQL. Последняя сложность часто преодолевается с помощью фреймворков приложений, которые скрывают ее (например, Django Haystack). Третий вариант — комбинированная  система, которая маскирует различия систем через промежуточное ПО, предоставляющее единый интерфейс.

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

Базы данных массивов

Существует множество областей вычислений, где массивы являются очевидным представлением данных. Мы используем термин «массив» для обозначения всех их вариантов: векторов (одномерных), матриц (двумерных) и тензоров (трехмерных и более). Например, в научных исследованиях географических регионов данные обычно представлены в виде многомерного массива, в котором хранятся координаты датчиков в зависимости от местоположения и времени: 

(latitude, longitude, time, [vector-of-values]) 

Некоторые другие наборы данных, включая геномное секвенирование и вычислительную гидродинамику, выглядят так же. Массивы — это основа большинства наборов данных для машинного обучения.

Хотя языки программирования, основанные на массивах, существуют с 1960-х годов (APL), создавать СУБД на основе модели данных массивов начали в 1980-х годах. PICDMS считается первой СУБД, использующей модель данных массивов. Самые старые СУБД на основе массивов, которые всё еще разрабатываются, —Rasdaman и kdb+, среди новых — SciDB и TileDB. HDF5 и NetCDF — популярные форматы файлов массивов для научных данных.

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

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

Обсуждение: СУБД, использующие массивы, — нишевый продукт, который применяется только в определенных вертикальных сегментах (мы обсудим векторные СУБД дальше). Например, они популярны в области геномики. HDF5 популярен для спутниковых изображений и других сетчатых научных данных. Однако бизнес-приложения редко используют специализированные СУБД на основе массивов, что необходимо для выживания любого продукта. Ни один крупный облачный провайдер не предлагает хостинг СУБД на основе массивов, а значит, не видит значительного  потенциала на рынке.

Проблема, с которой всегда сталкивались поставщики СУБД на основе массивов, заключается в том, что SQL включает поддержку упорядоченных массивов в качестве первоклассных типов данных (несмотря на то, что это противоречит исходному предложению РM). Первое предложение по расширению неупорядоченного набора на основе РM упорядоченными растрами было в 1993 году. Ранним примером этого был плагин временных (одномерных) данных Illustra. SQL:1999 ввел ограниченную поддержку одномерных фиксированной длины массивов. SQL:2003 расширился до поддержки вложенных массивов без заранее определенной максимальной кардинальности. Более поздние участники включают Oracle Georaster и Teradata. Кубы данных являются специализированными массивами, но колоночные СУБД превзошли их в поддержке OLAP-нагрузок из-за лучшей гибкости и более низких затрат на разработку.

В последнее время стандарт SQL:2023 включает поддержку настоящих многомерных массивов (SQL/MDA), вдохновленную RQL от Rasdaman. Это обновление позволяет SQL представлять массивы с произвольными измерениями, используя целочисленные координаты. По сути это позволяет кубам данных существовать в рамках SQL, но на этом рынке сейчас доминируют колоночные СУБД.

Векторные базы данных

Подобно тому, как модель семейств колонок упрощает модели документов, модель векторных данных упрощает модель данных массивов до одномерных растров. Поскольку векторные СУБД сейчас очень привлекательны для разработчиков и инвесторов (подобно всплеску интереса к NoSQL), обсудим их отдельно. Причина этого интереса заключается в том, что разработчики используют СУБД для хранения одномерных векторных представлений, сгенерированных с помощью инструментов ИИ. Эти инструменты используют полученные при обучении преобразования для конвертации данных записи (например, текста, изображения) в вектор, представляющий ее скрытые семантики. Например, можно преобразовать каждую статью Википедии в векторное представление, используя Google BERT, и хранить их в векторной базе данных вместе с дополнительными метаданными статьи: 

(title, date, author, [embedding-vector]) 

Размеры этих векторов варьируются от сотен измерений для простых трансформеров до тысяч для высококлассных моделей; эти размеры, очевидно, будут расти со временем по мере разработки более сложных моделей.

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

Чтобы избежать грубых сканирований для нахождения наиболее похожих записей, векторные СУБД строят индексы для ускорения поиска ближайших соседей (approximate nearest neighbor, ANN). Приложения отправляют запросы с предикатами как по индексу векторов, так и по невекторным атрибутам (то есть метаданным). СУБД затем выбирает, использовать ли предикат по невекторным атрибутам до (предфильтрация) или после (постфильтрация) векторного поиска.

В этой категории существуют десятки новых СУБД, среди которых ведущими системами являются Pinecone, Milvus и Weaviate. Поисковые системы, включая Elasticsearch, Solar и Vespa, расширили свои API для поддержки векторного поиска. Другие СУБД, такие как kdb+, переименовали себя в векторные базы данных, чтобы попасть в тренд.

Одной из привлекательных особенностей векторных СУБД является то, что они обеспечивают лучшую интеграцию с инструментами ИИ (например, ChatGPT, LangChain), чем реляционные СУБД. Эти системы нативно поддерживают преобразование данных записи в векторное представление при вставке с использованием этих инструментов, а затем используют то же преобразование для конвертации входных аргументов запроса в векторное представление для выполнения ANN-поиска; другие СУБД требуют, чтобы приложение выполняло эти преобразования вне базы данных.

Обсуждение: В отличие от СУБД массивов, которым требуется кастомный менеджер хранения и движок выполнения для поддержки эффективных операций с многомерными данными, векторные СУБД по сути являются документо-ориентированными СУБД со специализированными ANN-индексами. Такие индексы являются функцией, а не основой новой архитектуры системы. Меньше чем через год после того как большие языковые модели стали мейнстримом с ChatGPT (в конце 2022 года) несколько реляционных СУБД добавили свои собственные расширения для векторного поиска. В 2023 году многие крупные реляционные СУБД добавили векторные индексы, включая Oracle, SingleStore, Rockset и ClickНouse. Это контрастирует с поддержкой JSON в реляционных СУБД. NoSQL-системы MongoDB и CouchDB стали популярны в конце 2000-х годов, а на то, чтобы добавить их поддержку в реляционные СУБД, ушло несколько лет.

Существует два вероятных объяснения быстрого распространения векторных индексов. Первое заключается в том, что поиск по аналогии через векторные представления настолько привлекателен, что каждый поставщик СУБД поспешил выпустить свою версию и немедленно объявил о ней. Второе заключается в том, что инженерные усилия по введению новой структуры данных индекса достаточно малы, чтобы внедрение векторного поиска не заняло много времени у поставщиков СУБД. Большинство из них не писали свои векторные индексы с нуля, а интегрировали библиотеку с открытым исходным кодом (например, pgVector, DiskANN, FAISS).

Мы ожидаем, что векторные СУБД пройдут ту же эволюцию, что и документо-ориентированные СУБД: добавят функции, чтобы стать более похожими на реляционные (например, SQL, транзакции, расширяемость). Тем временем реляционные лидеры добавят векторные индексы к своему длинному списку функций и перейдут к следующей тенденции.

Графовые базы данных

В последнее десятилетие в академической среде и индустрии наблюдается значительный интерес к графовым базам данных. Многие приложения используют графы знаний для моделирования полуструктурированной информации. Приложения социальных сетей по своей природе содержат графовые отношения («лайки», «друзья»). Инструменты проектирования реляционных баз данных предоставляют пользователям модель сущность – связь (entity – relationship, ER).  ER-диаграмма — это граф, поэтому такая парадигма имеет очевидные области применения.

Существует два наиболее распространённых подхода к представлению графов: (1) модель ресурсного описания (resource description framework, RDF) и (2) графы свойств (property graph). В графах свойств СУБД сохраняет структуру направленного мультиграфа, который поддерживает метки ключ – значение для узлов и ребер. RDF-базы данных (также известные как триплсторы (triplestores – 3 значения)) моделируют только направленный граф с метками на ребрах. Поскольку графы свойств более распространены и являются суперсетом RDF, мы будем обсуждать только их. Рассмотрим два случая использования графовых СУБД и обсудим, почему их внедрение ограничено.

Первая категория систем предназначена для операционных или OLTP-нагрузок: например, приложение добавляет в базу данных ссылку, обновляя одну запись, предположительно транзакционным образом. Neo4j — самая популярная графовая СУБД для OLTP-приложений. Она поддерживает ребра с использованием указателей (как в CODASYL), но не объединяет узлы с их родителями или потомками. Такая архитектура выгодна для прохода длинных цепочек ребер, поскольку она будет следовать указателям, тогда как реляционная СУБД должна делать это через join’ы. Но их потенциальный рыночный успех зависит от того, будет ли достаточно длинных цепочек сценариев, чтобы отказаться от реляционной СУБД.

Второй случай использования — аналитика, которая стремится извлечь информацию из графа. Пример такого сценария — определение, у какого пользователя больше всего друзей младше 30 лет. Известные решения, такие как Tigergraph и JanusGraph, сосредоточены на языках запросов и хранении данных в графовой СУБД. Другие системы, такие как Giraph и Turi(ранее Graphlab), предоставляют вычислительную основу для поддержки параллельного выполнения графоориентированных программ, обычно написанных пользователем.

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

Обсуждение: Независимо от того, ориентирована графовая СУБД на OLTP- или OLAP-нагрузки, ключевой проблемой, с которой сталкиваются эти системы, является возможность моделировать граф как коллекцию таблиц:

Node (node_id, node_data)

Edge (node_id_1, node_id_2, edge_data)

Это означает, что реляционные СУБД — вариант для поддержки графов. Но «обычный» SQL недостаточно выразителен для графовых запросов и требует нескольких клиент-серверных взаимодействий для операций прохода по графу.

Некоторые реляционные СУБД, включая MSSQL и Oracle, предоставляют встроенные расширения SQL, которые упрощают хранение и запрос графовых данных. Другие СУБД используют слой преобразования поверх отношений для поддержки графоориентированных API. Amazon Neptune представляет собой графоориентированное покрытие поверх Aurora MySQL. Apache AGE предоставляет интерфейс OpenCypher поверх PostgreSQL.

Совсем недавно стандарт SQL:2023 включил запросы графов свойств (SQL/PGQ) для определения и обхода графов в реляционной СУБД. Синтаксис базируется на существующих языках (например, Cypher от Neo4j, PGQL от Oracle и GSQL от TigerGraph) и включает аспекты разрабатываемого стандарта GQL. Таким образом, SQL/PGQ еще больше сужает функциональные различия между реляционными и нативными графовыми СУБД.

Вопрос в том, смогут ли поставщики графовых СУБД сделать свои специализированные системы достаточно быстрыми, чтобы преодолеть вышеуказанные недостатки. Несколько исследований производительности показывают, что моделирование графов на реляционных СУБД превосходит графовые СУБД. Более свежая работа показала, как SQL/PGQ в DuckDB превосходит ведущую графовую СУБД до 10 раз. Эта тенденция продолжится с дальнейшими улучшениями оптимальных соединений в худшем случае и алгоритмов факторизованного выполнения для графовых запросов в реляционных СУБД.

Резюме

Из раздела выше можно резонно заключить, что NoSQL, нереляционные системы, либо относятся к нишевому рынку, либо быстро превращаются в SQL/РМ-системы. В частности:

• Системы MapReduce умерли несколько лет назад и сейчас в лучшем случае устарели.

• Хранилища «ключ – значение»: многие либо эволюционировали в РМ-системы, либо используются только для решения специфических задач. Современные высокопроизводительные реляционные СУБД могут как минимум сравниться с ними, а часто превосходят их.

• Документноориентированные базы данных: такие NoSQL-системы находятся на пути к сближению с реляционными СУБД. Различия между этими двумя типами систем со временем сократились и в будущем могут стать практически неразличимыми.

• Системы column-family остаются нишевым рынком. Если бы не Google, мы бы не стали упоминать эту категорию в статье.

• Текстовые поисковые системы используются для текстовых полей в полисторной архитектуре. Если бы реляционные СУБД имели лучшее решение для поиска, их не пришлось бы выделять в отдельный продукт.

• Базы данных массивов: научные приложения продолжат игнорировать реляционные СУБД в пользу специально разработанных систем массивов. Важность  этих систем может возрасти, поскольку реляционные СУБД не могут эффективно хранить и анализировать массивы, несмотря на новые улучшения SQL/MDA.

• Векторные базы данных: реляционные СУБД с индексами для ускорения поиска ближайших соседей. РМ-СУБД вскоре должны предоставить нативную поддержку для таких структур данных и методов поиска за счет расширения типов систем. Как следствие, такие специализированные базы данных окажутся не нужны.

• Графовые базы данных: графовые OLTP-приложения будут в значительной степени обслуживаться реляционными СУБД. Аналитические графовые приложения имеют уникальные требования, которые лучше всего реализовывать в оперативной памяти с использованием специализированных структур данных. СУБД будут предоставлять API, ориентированные на графы, поверх SQL или через расширения. Мы не думаем, что специализированные графовые СУБД займут значительную долю рынка.

Случается, что ребрендинг предыдущих моделей данных выдают за что-то новое. Например, графо-реляционная модель по сути является семантической моделью данных. Аналогично, документо-реляционная модель — это документная модель с внешними ключами. Есть случаи, когда NoSQL-интерфейс предоставляется поверх реляционной СУБД (например, PRQL, Malloy). Хотя эти языки исключают некоторые недостатки SQL, они недостаточно убедительны, чтобы охватить уже закрепившуюся пользовательскую базу и экосистему SQL.

Архитектуры систем

За последние двадцать лет в архитектуре СУБД появилось множество новых идей, которые отражают изменения характеристик приложений и оборудования. Среди таких идей встречаются как потрясающие, так и спорные — обсудим их по порядку.

Колоночные системы

Чтобы понять привлекательность колоночных СУБД, расскажем о возникновении рынка хранилищ данных (OLAP). Начиная с середины 1990-х годов, компании начали собирать данные (обычно по продажам) о своих клиентах. Розничные продавцы (например, Walmart) выступали в авангарде создания исторических баз данных о продажах. Выяснилось, что хранилище данных о продажах окупается за полгода благодаря лучшим решениям по заказу и ротации товаров. Теперь базы данных для работы с клиентами используются повсеместно.

Приложения хранилищ объединяют общие свойства, чем и отличаются от OLTP-нагрузок:

1. Имеют исторический характер (загружаются периодически, доступны только для чтения).

2. Организации хранят все данные (от терабайтов до петабайтов) столько, сколько позволяет хранилище.

3. Запросы обычно обращаются только к небольшому подмножеству атрибутов из таблиц и носят произвольный характер.

Ральф Кимбалл был одним из первых популяризаторов моделирования данных для хранилищ по схеме «звезда». Идея заключалась в создании таблицы фактов, содержащей данные транзакций на уровне элементов. Классический пример — таблица фактов, которая содержит запись для каждого товара, приобретенного в розничной компании. Вокруг таблицы фактов размещаются таблицы измерений с общей информацией, выделенной из таблицы фактов для экономии места. В условиях розничной торговли эти таблицы измерений будут включать информацию о клиентах, продуктах, магазинах и времени.

Организация хранилища СУБД по колонкам, а не по строкам имеет несколько преимуществ. Во-первых, сжатие колоночных данных более эффективно, чем данных, основанных на строках, потому что в блоке данных присутствует единственный тип значения, часто представляющий собой множество повторяющихся байтов. Во-вторых, движок в стиле Volcano выполняет операции по одной на каждую строку. Колоночно-ориентированный движок, напротив, имеет внутренний цикл, который обрабатывает целую колонку с использованием векторных инструкций. Наконец, строка таблицы имеет длинный заголовок для каждой записи (например, 20 байт) для отслеживания NULL’ов и метаданных версий, тогда как колоночные хранилища имеют минимальные накладные расходы хранения каждой записи.

Обсуждение: за последние два десятилетия все активные вендоры на рынке хранилищ данных конвертировали свои предложения со строкового в колоночный формат. Этот переход привел к значительным изменениям в дизайне СУБД. Кроме того, за последние два десятилетия на рынок вышли несколько новых вендоров с предложениями колоночных хранилищ, например, Redshift от Amazon и BigQuery от Google, и независимые компании (например, Snowflake).

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

Облачные базы данных

Рост облачных платформ в конце 2000-х годов также сильно повлиял на реализацию (и модель продаж) СУБД. Первые облачные предложения СУБД представляли собой переработанные системы для локального развертывания в управляемые виртуальные машины с подключенными дисками. Однако за последние 20 лет пропускная способность сетей увеличивалась значительно быстрее, чем пропускная способность дисков, поэтому сетевые системы хранения (network attached storage, NAS) стали привлекательнее подключаемых дисков. Это вызвало серьезное переосмысление архитектур СУБД для облака.

Все крупные облачные поставщики предлагают NAS через объектные хранилища (например, Amazon S3) с некоторыми функциями СУБД (например, репликация, фильтрация). Помимо лучших экономических показателей по сравнению с подключаемыми дисками, объектные хранилища компенсируют затраты на добавленное сетевое соединение. Во-первых, вычислительные узлы не связаны напрямую с узлами хранения, и система может обеспечивать эластичность на уровне запроса; СУБД может динамически добавлять новые вычислительные узлы без необходимости перестраивать данные. Это позволяет СУБД использовать различное оборудование для узлов хранения и вычислительных узлов. Во-вторых, система может переназначать вычислительные узлы для выполнения других задач, если СУБД недостаточно загружена. С другой стороны, в СУБД с разделением ресурсов узел должен всегда быть онлайн, чтобы обрабатывать входящие запросы. Наконец, возможно (и обычно выгодно) выполнение вычислений на узлах хранения. Эта стратегия выполнения известна как «приближение запроса к данным» vs «перемещение данных к запросу» и хорошо известна в СУБД.

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

Обсуждение: появление облачных баз данных — еще один пример того, что всё новое — это хорошо забытое старое. Многозадачные СУБД с разделяемым диском — старая идея, которая раньше не приносила успеха, но снова стала популярной благодаря изменениям в технологиях (ускорению сетей) и переходу в облако. Сервисы с разделением времени были популярны в 1970-х годах, когда компьютеры были большими и дорогими. Облачные платформы — это крупные сервисы разделения времени, так что концепция вернулась спустя несколько десятилетий. Поскольку предприятия переносят в облако всё, что могут, архитектура с разделяемым диском будет доминировать в СУБД. А значит, возрождение архитектур типа shared-nothing (без разделяемых ресурсов) не предвидится.

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

С точки зрения бизнеса, опасностью для опенсорсных СУБД может стать их слишком большая популярность и монетизизация крупными облачными провайдерами. Яркие тому примеры — публичные конфликты между Amazon и независимыми провайдерами программного обеспечения, такими как MongoDB и Elasticsearch.

Озера данных / Lakehouses

Ещё один тренд, который раздули облачные платформы, — отход от монолитных специализированных хранилищ данных для OLAP-нагрузок в сторону озер данных, поддерживаемых объектными хранилищами. Компании как правило загружали данные в СУБД, которая сохраняла их в управляемом хранилище с проприетарными форматами. Вендоры считали, что их СУБД должны отвечать за всё, что относится к данным, но в последние 10 лет это не соответствовало моделям работы многих компаний, особенно технологических.

В архитектуре Data Lake приложения загружают файлы в распределенное объектное хранилище, минуя традиционный путь через СУБД. Пользователи выполняют запросы и обработку накопленных файлов, используя lakehouse (гибрид хранилища данных и озера данных). Такие lakehouse-системы обеспечивают единую инфраструктуру, поддерживающую как SQL-, так и NoSQL-нагрузки. Это особенно важно, так как за последнее десятилетие стало очевидно, что специалисты по Data Science и машинному обучению для доступа к данным вместо SQL используют Python-блокноты с API DataFrame pandas. Несколько проектов используют методы СУБД для оптимизации обработки DataFrame, включая Dask, Polars, Modin и Bodo.

Вместо использования проприетарных форматов файлов, специфичных для СУБД, или неэффективных текстовых файлов (например, CSV, JSON), приложения записывают данные в озера данных, используя открытые дисковые форматы файлов. Два самых популярных формата — Parquet от Twitter/Cloudera и ORC от Meta. Оба заимствуют техники из более ранних исследований колоночного хранения, такие как PAX, сжатие и обработка вложенных данных (JSON). Apache Arrow — аналогичный бинарный формат для обмена данными в памяти между системами. Открытые библиотеки для чтения/записи этих форматов позволяют различным приложениям создавать файлы данных, которые затем могут быть разобраны и использованы другими системами, что улучшает обмен данными между сервисами и бизнес-единицами.

Обсуждение: озера данных — преемники движения Big Data начала 2010-х годов, частично вызванного популярностью MR-систем и колоночных хранилищ. На первый взгляд, озеро данных кажется ужасной идеей для организации: разрешение любому приложению записывать произвольные файлы в центральное хранилище без какой-либо системы управления — верный путь обрести проблемы с целостностью, обнаружением и версионированием данных. Lakehouses предоставляют столь необходимый контроль над этими средами, помогая решить многие проблемы с метаданными, кэшированием и индексированием. Дополнительное программное обеспечение, которое отслеживает новые данные и поддерживает транзакционные обновления, такие как Delta Lake, Iceberg и Hudi, делает lakehouses более похожими на традиционное хранилище данных.

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

Все крупные облачные вендоры теперь предлагают различные варианты управляемых сервисов озер данных. Поскольку системы озер данных, поддерживаемые объектными хранилищами, намного дешевле в пересчете на гигабайт, чем проприетарные хранилища данных, традиционные поставщики OLAP (например, Teradata, Vertica) расширили свои СУБД для поддержки чтения данных из объектных хранилищ в ответ на ценовое давление. Также на этом рынке присутствуют несколько независимых систем, включая Databricks, Dremio, PrestoDB и Trino.

Системы NewSQL

В конце 2000-х годов появилось множество распределённых NoSQL-СУБД, разработанных для горизонтального масштабирования и поддержки онлайн-приложений с большим количеством одновременных пользователей. Однако многие организации не могли использовать эти NoSQL-системы, так как их приложения не могли отказаться от строгих транзакционных требований. При этом существующие реляционные СУБД (особенно с открытым исходным кодом) не могли (нативно) масштабироваться на несколько машин. В ответ на это в начале 2010-х годов появились системы NewSQL, стремящиеся обеспечить масштабируемость NoSQL-систем для OLTP-нагрузок, сохраняя поддержку SQL. Иными словами, эти новые системы стремились достичь такой же масштабируемости, как NoSQL-СУБД 2000-х годов, но при этом сохранить реляционную модель данных и транзакции ACID, характерные для СУБД 1990-х годов.

Существовало две основные группы систем NewSQL. Первая включала СУБД, работающие в оперативной памяти, такие как H-Store (коммерциализованнная под именем VoltDB), SingleStore, Microsoft Hekaton и HyPer. Другие стартапы предлагали диск-ориентированные распределённые СУБД, такие как NuoDB и Clustrix.

Обсуждение: пока не произошло резкого роста внедрения СУБД NewSQL. Причина слабого интереса в том, что существующие СУБД были достаточно хороши для своего времени и компании не были готовы нести расходы и риски, связанные с миграцией существующих приложений на новые технологии  Компании более чувствительны к рискам при миграции OLTP-СУБД, чем при миграции  OLAP-СУБД. Если OLTP-СУБД выходит из строя, компании не могут выполнять необходимые транзакции для получения дохода. В то время как сбой OLAP СУБД может лишь временно затруднить работу аналитика или специалиста по данным.

Существовали и другие ограничения в системах NewSQL, такие как поддержка только подмножества стандартного SQL или плохая производительность при транзакциях на нескольких узлах. Некоторые продукты NewSQL, такие как Hekaton от Microsoft, были доступны только в виде расширения для традиционной СУБД, что требовало использования более медленных интерфейсов традиционной СУБД для работы с более быстрым движком. 

Поставщики NewSQL также ошибочно предполагали, что внедрение СУБД, работающих в оперативной памяти, в последнее десятилетие будет более значительным. Поставщики флэш-памяти снижали стоимость, улучшая плотность хранения, пропускную способность и задержки. Более высокие затраты на оперативную память и прекращение разработки постоянной памяти (например, Intel Optane) означают, что SSD останутся доминирующими для OLTP-СУБД.

В результате развития NewSQL появилась новая волна распределённых транзакционных SQL-СУБД. Среди них TiDB, CockroachDB, PlanetScale (основанная на ПО для шардирования Vitess) и YugabyteDB. Крупные поставщики NoSQL также добавили поддержку транзакций в свои системы за последнее десятилетие, несмотря на утверждения о том, что они не нужны. MongoDB, Cassandra и DynamoDB оказались среди СУБД, которые перешли на транзакции. Конечно, это связано с требованиями клиентов, которые настаивали на необходимости транзакций. Google убедительно доказал это, отказавшись от конечной согласованности в пользу реальных транзакций с системой Spanner в 2012 году.

Аппаратные ускорители

Последние 50 лет отличались активными поисками экономически эффективного аппаратного ускорителя для СУБД. Цель очевидна: оборудование, разработанное специально для СУБД, легко превзойдет обычный процессор.

В 1980-х годах поставщики разрабатывали спецоборудование для ускорения СУБД и продвигали его как «машины баз данных». Britton-Lee в 1981 году выпустила первый коммерческий ускоритель (IDM/500), который содержал обычный процессор с аппаратным ускорителем, частично разгружающим исполнение запроса. Этот ускоритель был ориентирован на небольшую часть процесса исполнения и оказался экономически неэффективным. Teradata представила свою собственную машину баз данных, которая обеспечивала сетевое оборудование для сортировки на лету (Y-net), но позже отказалась от него в пользу чисто программного решения. Все остальные попытки создания специализированного аппаратного ускорения для СУБД в 1980-х годах провалились.

Вместо разработки специализированного оборудования для СУБД в последние 20 лет  для ускорения выполнения запросов использовали стандартное оборудование (FPGA, GPU). Эта идея привлекательна тем, что вендор может получить выгоду от ускорителя СУБД без затрат на производство оборудования.

Netezza была одной из первых СУБД на основе FPGA, которая появилась в конце 1990-х годов как форк PostgreSQL. Она использовала FPGA для ускорения поиска на страницах, хранящихся на диске, но изначально не могла выполнять поиск по страницам в памяти. Позже Netezza устранила это ограничение. Компания Swarm64 пыталась продать FPGA-ускоритель для PostgreSQL, но перед собственной продажей переключилась на архитектуру без FPGA, основанную только на программном обеспечении. Deepgreen DB от Vitesse — единственная оставшаяся на рынке СУБД с FPGA от независимого поставщика ПО.

Очень активен рынок СУБД с GPU-ускорителями, такими как Kinetica, Sqream, Brytlyt и HeavyDB. Если данные не помещаются в память GPU, то выполнение запроса тормозится на этапе загрузки данных на устройство, а преимущества аппаратной параллелизации  теряют смысл.

Обсуждение: Из приведенного выше анализа можно сделать несколько выводов. Во-первых, все эти системы сосредоточены на рынке OLAP и предназначены только для реляционных СУБД; обсуждение в этом разделе практически не затрагивает модель данных. Кроме того, OLAP-нагрузки будут продолжать активно переходить в облако, но спецоборудование вряд ли завоюет популярность, если его не создаст сам облачный вендор.

Создание специализированного оборудования только для СУБД экономически невыгодно для большинства компаний. Обычное оборудование решает эту проблему, но по-прежнему сложно интегрируется в СУБД. Причина, по которой на рынке больше СУБД с GPU, чем с FPGA, в наличии библиотек поддержки для GPU (например, Nvidia CUDA). Но вычислительные ресурсы на базе CPU в облаке чрезвычайно дешевы благодаря экономии на масштабе. Успех любого ускорителя будет ограничен только локальными базами данных, но этот рынок не растет такими же темпами, как облачные базы данных.

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

Специализированные аппаратные ускорители смогут стать успешными только у  крупных облачных вендоров, которым по силам потратить $50–100 млн на исследования и разработку специализированного оборудования больших масштабов. Они контролируют весь стек (аппаратное и программное обеспечение) и могут интегрировать свое оборудование в критически важных местах. Amazon уже сделала это со своими ускорителями Redshift AQUA. У Google BigQuery есть собственные компоненты для пересылки данных в памяти.

Несмотря на высокие шансы, мы прогнозируем в ближайшие два десятилетия множество попыток в этом направлении.

Базы данных на основе блокчейна

На момент написания этой главы технология блокчейна теряет популярность. Блокчейн — это децентрализованные базы данных с лог-структурой (журналы), которые поддерживают инкрементные контрольные суммы с использованием различных вариантов деревьев Меркла. Эти контрольные суммы обеспечивают неизменяемость записей в журнале базы данных: приложения используют их для проверки того, что предыдущие обновления базы данных не изменялись.

Идеальный случай применения баз данных на блокчейне — это одноранговые приложения, где нельзя доверять никому. В таких системах нет центрального органа, который контролировал бы порядок обновлений базы данных. В реализации блокчейна используется протокол фиксации BFT (Byzantine Fault Tolerance), чтобы определить, какую транзакцию следует применить к базе данных следующей.

На данный момент криптовалюты (например, Bitcoin) являются единственным случаем использования блокчейна. На его основе пытались создать удобные СУБД, такие как Fluree, BigChainDB и ResilientDB. Их вендоры (ошибочно) утверждают, что блокчейн обеспечивает лучшую безопасность и возможность аудита, недоступные в других СУБД.

Обсуждение: В реальной жизни нам приходится доверять разным организациям, например, при продаже дома — титульной компании для управления транзакцией. Без доверия обходятся только взаимодействия в даркнете (например, при отмывании денег). Законный бизнес не готов нести затраты (величиной около пяти порядков) на использование СУБД на основе блокчейна. Если организации доверяют друг другу, они могут использовать распределенную СУБД гораздо эффективнее и без траты времени на блокчейн. Насколько нам известно, все крупные криптовалютные биржи ведут свой бизнес на традиционных реляционных СУБД, а не на блокчейн-системах.

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

Возможно, существует (небольшой) рынок частных СУБД на основе блокчейна. Amazon Quantum Ledger Database (QLDB), выпущенная в 2018 году, обеспечивает такие же гарантии неизменяемости и проверяемости обновлений, как и блокчейн, но не является децентрализованной (то есть без протокола фиксации BFT). Amazon создала QLDB после того, как не нашла убедительных аргументов для использования полностью децентрализованной блокчейн-СУБД .

Резюме

Основные выводы по итогам анализа крупных технологических направлений в СУБД таковы:

• Колоночные системы: Переход на колоночное хранилище совершил революцию в архитектуре СУБД для OLAP.

• Облачные базы данных: Облако изменило устоявшиеся взгляды на создание масштабируемых СУБД. Любой продукт, не начинающий с облачного решения, за исключением встроенных СУБД, скорее всего, потерпит неудачу.

• Озера данных / Lakehouses: Облачное объектное хранилище с открытым исходным кодом станет архетипом СУБД для OLAP на следующие десять лет.

• NewSQL-системы: Привносят новые идеи, но пока не настолько влиятельны, как колоночные и облачные СУБД. Привели к появлению новых распределенных СУБД, поддерживающих более сильную семантику ACID, в противовес более слабым гарантиям BASE в NoSQL.

• Аппаратные ускорители: Пока используются только у крупных облачных поставщиков, хотя стартапы не оставят попытки.

• Базы данных на блокчейне: Неэффективная технология, которая ищет себе применение. История показывает, что это неправильный подход к разработке систем.

Заключительные комментарии

Анализ баз данных последних двух десятилетий привел к важным выводам. К сожалению, некоторые из них повторяют предупреждения из статьи 2005 года.

Никогда не недооценивайте силу хорошего маркетинга для плохих продуктов. Рынок баз данных чрезвычайно конкурентен и приносит большую прибыль. Эта конкуренция заставляет вендоров заявлять, что их новые технологии решат все проблемы и сделают жизнь разработчиков лучше. Каждый разработчик сталкивался с трудностями при работе с базами данных, поэтому все они особенно восприимчивы к такому маркетингу. Некачественные СУБД добились успеха благодаря сильному маркетингу, несмотря на наличие лучших вариантов: Oracle сделал это в 1980-х годах, MySQL в 2000-х, а MongoDB в 2010-х. Эти системы получили достаточное распространение на ранних этапах, что позволило им выиграть время для устранения накопленного технического долга.

Остерегайтесь СУБД крупных компаний, не связанных с базами данных. В последнее десятилетие появилась тенденция, когда технологические компании создают внутренние СУБД, а затем выпускают их как проекты с открытым исходным кодом (часто передавая его под управление Apache Foundation) в надежде получить «бесплатную» разработку от внешних пользователей.

Иногда такие системы создают крупные компании, которые могут позволить себе выделять ресурсы на разработку новых систем. Примеры — Meta (Hive, Presto, Cassandra, RocksDB) и LinkedIn (Kafka, Pinot, Voldemort). С другой стороны стартапы создают продукты, которые активно работают с данными и нуждаются в СУБД. Самые успешные примеры — 10gen (MongoDB) и PowerSet (HBase), но было много и неудачных попыток.

Эта тенденция избегать использования «непридуманных здесь» программных решений частично связана с тем, что создание новых внутренних систем, даже если существующих инструментов достаточно, помогает инженерам продвинуться по карьерной лестнице. Такая практика привела к тому, что многие команды без опыта проектирования СУБД взялись за создание новых систем. Будьте осторожны, если компания впервые выпускает системы с открытым исходным кодом, так как это почти всегда незрелые технологии.

Не игнорируйте опыт пользователя сразу после установки. Одним из ключевых аргументов в пользу многих нереляционных СУБД является более удобный «первоначальный» опыт по сравнению с реляционными СУБД. Большинство SQL-систем требуют сначала создать базу данных, затем определить таблицы и лишь потом загружать данные. Поэтому дата-сайентисты используют блокноты Python для быстрого анализа файлов данных. Каждая СУБД должна, таким образом, облегчить обработку файлов из локального и облачного хранилища. Растущая популярность DuckDB отчасти объясняется тем, что она хорошо справляется с этой задачей.

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

Разработчики должны напрямую работать с базой данных. Большинство OLTP-приложений, созданных за последние 20 лет, в основном взаимодействуют с базами данных через абстрактный слой, такой как API для конечных точек (например, REST, GraphQL) или библиотека ORM (Object-Relational Mapper). Такие слои переводят высокоуровневые запросы приложения в запросы к базе данных. ORM также автоматически обрабатывают задачи обслуживания, такие как миграция схем. Поскольку разработчики OLTP никогда не пишут на чистом SQL в своих приложениях, модель данных их СУБД не имеет значения, так как слои скрывают это.

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

Влияние ИИ/МL на СУБД будет значительным. В последнее время важным вопросом стало то, как СУБД должны взаимодействовать с современными инструментами ИИ/МО, особенно с появлением LLM (например, ChatGPT). Хотя эта область быстро развивается, мы дадим несколько комментариев.

Естественные языки (natural languages, NL) снова используются для запросов к базам данных благодаря достижениям LLM в преобразовании NL в код запросов (например, SQL). Некоторые даже предполагают, что такие интерфейсы запросов на основе ИИ отправят SQL на покой. Интерфейсы NL — это старая исследовательская тема, которая восходит к 1970-м годам, но исторически имела плохие результаты и слабо распространилась. Мы признаем, что LLM показывают впечатляющие результаты для этой задачи, но предостерегаем тех, кто думает, что NL заменит SQL. Никто не будет писать OLTP-приложения на NL, так как большинство запросов генерируется с использованием ORM. Для OLAP-баз данных NL может быть полезен при создании начальных запросов для исследовательского анализа. Однако эти запросы должны быть доступны для уточнения в инструменте, похожем на панель управления, так как английский и другие NL полны двусмысленностей и неточностей.

Существует предубеждение против того, чтобы полагаться на текущие технологии LLM для принятия внутренних решений, особенно в отношении финансовых данных. Главная проблема в том, что выводы LLM не объяснимы для человека. Во-вторых, системы LLM требуют больше тренировочных данных, чем «традиционные» системы МL (например, случайные леса, байесовские модели). Компании, как правило, не могут поручить создание тренировочных данных для этих моделей неквалифицированным людям. По этим причинам использование LLM для корпоративных данных будет проходить осторожно и медленно.

Наконец, множество недавних исследований были посвящены использованию ИИ/МО для оптимизации СУБД: оптимизаторам запросов, ориентированным на МL, настройку конфигураций и методы доступа. Хотя такие оптимизации с помощью МL являются мощными инструментами для улучшения производительности СУБД, это не устраняет необходимости в высококачественном системном инжиниринге.

Заключение

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

Другая проблема — напрасные усилия новых проектов по повторной реализации одних и тех же компонентов, не новых, но необходимых для создания готовой к производству СУБД (например, обработчиков конфигурации, парсеров, буферных пулов). Чтобы ускорить создание следующего поколения СУБД, сообщество должно способствовать разработке многократно используемых компонентов и сервисов с открытым исходным кодом. В настоящее время предпринимаются определенные усилия для достижения этой цели, в том числе для форматов файлов, оптимизации запросов (например, Calcite, Orca) и движков (например, DataFusion, Velox). Мы утверждаем, что сообщество баз данных должно стремиться к POSIX-подобному стандарту внутреннего устройства СУБД, чтобы ускорить взаимодействие.

Советуем разработчикам учиться на историческом опыте: вставайте на плечи тех, кто пришел раньше, а не на их пальцы. А мы, может быть, напишем продолжение этой статьи в 2044 году.

Список литературы, на которую ссылаются авторы статьи, можно найти в публикации на нашем сайте.