Всё новое — это хорошо забытое старое. Продолжение

Michael Stonebraker, Massachusetts Institute of Technology, stonebraker@csail.mit.edu
Andrew Pavlo, Carnegie Mellon, University pavlo@cs.cmu.edu

Оригинал статьи: https://db.cs.cmu.edu/papers/2024/whatgoesaround-sigmodrec2024.pdf

Аннотация

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

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

Введение

В 2005 году один из нас написал для Red Book¹ главу под названием What Goes Around Comes Around («Что посеешь, то и пожнёшь») [188]. В ней рассматривались основные этапы развития моделирования данных, начиная с 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 году как точечное решение для обработки результатов своего периодического обхода интернета [122]. В то время у 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 [134]. Появилось несколько стартапов для поддержки Hadoop на коммерческом рынке. Мы будем обозначать MR реализацию Google, а Hadoop   —опенсорсную версию. Они функционально схожи.

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

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

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

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

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

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

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

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

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

(key, value)

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Если join не является отношением один ко многим, то данные будут дублироваться.
2. Предварительные join не всегда быстрее, чем обычные.
3. Отсутствует независимость данных.

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

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

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

Языки более высокого уровня почти универсально предпочитаются по сравнению с нотациями, работающими только с одной записью за раз, так как они требуют меньше кода и обеспечивают большую независимость данных. Первые оптимизаторы 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 году [111]. Вместо SQL и появляющегося колоночного хранилища Google использовал эту модель данных с процедурными клиентскими API. Другие системы приняли модель column-family, пытались скопировать уникальную реализацию Google. Самые известные — Cassandra [14] и HBase [28]. Они скопировали и ограничения BigTable, в том числе отсутствие join’ов и вторичных индексов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Node (node_id, node_data)
Edge (node_id_1, node_id_2, edge_data)

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

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

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

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

Резюме

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

• Системы MapReduce умерли несколько лет назад и сейчас в лучшем случае устарели.
• Хранилища «ключ – значение»: многие либо эволюционировали в РМ-системы, либо используются только для решения специфических задач. Современные высокопроизводительные реляционные СУБД могут как минимум сравниться с ними, а часто превосходят их.
• Документноориентированные базы данных: такие NoSQL-системы находятся на пути к сближению с реляционными СУБД. Различия между этими двумя типами систем со временем сократились и в будущем могут стать практически неразличимыми.
• Системы column-family остаются нишевым рынком. Если бы не Google, мы бы не стали упоминать эту категорию в статье.
• Текстовые поисковые системы используются для текстовых полей в полисторной архитектуре. Если бы реляционные СУБД имели лучшее решение для поиска, их не пришлось бы выделять в отдельный продукт.
• Базы данных массивов: научные приложения продолжат игнорировать реляционные СУБД в пользу специально разработанных систем массивов. Важность  этих систем может возрасти, поскольку реляционные СУБД не могут эффективно хранить и анализировать массивы, несмотря на новые улучшения SQL/MDA.
• Векторные базы данных: реляционные СУБД с индексами для ускорения поиска ближайших соседей. РМ-СУБД вскоре должны предоставить нативную поддержку для таких структур данных и методов поиска за счет расширения типов систем. Как следствие, такие специализированные базы данных окажутся не нужны.
• Графовые базы данных: графовые OLTP-приложения будут в значительной степени обслуживаться реляционными СУБД. Аналитические графовые приложения имеют уникальные требования, которые лучше всего реализовывать в оперативной памяти с использованием специализированных структур данных. СУБД будут предоставлять API, ориентированные на графы, поверх SQL или через расширения. Мы не думаем, что специализированные графовые СУБД займут значительную долю рынка.

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

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

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

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

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

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

1. Имеют исторический характер (загружаются периодически, доступны только для чтения).
2. Организации хранят все данные (от терабайтов до петабайтов) столько, сколько позволяет хранилище.
3. Запросы обычно обращаются только к небольшому подмножеству атрибутов из таблиц и носят произвольный характер.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Системы NewSQL

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Резюме

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

• Колоночные системы: Переход на колоночное хранилище совершил революцию в архитектуре СУБД для 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.

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

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

Примечания переводчика 

[1]     Red Book – сборник статей Readings in Database Systems под ред. П. Бейлиса, Дж. М. Хиллерстейна и М. Стоунбрейкера http://www.redbook.io/ 

[2]     Термин «Semistructured data» чаще переводится на русский как слабоструктурированные данные, реже встречаются «полуструктурированные». В любом случае, это одно и тоже. 

[3]     Эта «проблема» заключается в том, что для извлечения объекта с вложенной структурой, разложенной по различным таблицам, требуются запросы во все эти таблицы (возможно, объединённые с помощью JOIN). 

[4]     Не путайте клики в графе и клики мышью 

Список источников

[1] TeraData Forums. https://downloads.teradata.com/forum/
database/what-is-the-difference-between-a-ynet-andbynet, September 2011.
[2] Netezza TwinFin Architecture. https://www.iexpertify.com/learn/netezza-twinfin-architecture/#.YYq5_S1h17Y, April 2020.
[3] Graph processing with sql server and azure sql database. https://docs.microsoft.com/en-us/sql/relationaldatabases/graphs/sql-graph-overview, 2021.
[4] Georaster in oracle database. https://www.oracle.com/a/tech/docs/georaster-2021.pdf, mar 2021.
[5] Apache Hudi. https://hudi.apache.org/, 2023.
[6] Apache Iceberg. https://iceberg.apache.org/, 2023.
[7] Oracle introduces integrated vector database to augment generative ai and dramatically increase developer productivity. https://www.oracle.com/news/announcement/ocwintegrated-vector-database-augments-generative-ai2023-09 19/, sep 2023.
[8] Introducing vector search on rockset. https://rockset.com/blog/introducing-vector-search-on-rockset/, apr 2023.
[9] Aerospike AQL. https://docs.aerospike.com/tools/aql,2024.
[10] Apache AGE. https://age.apache.org, 2024.
[11] Apache Arrow. https://arrow.apache.org, 2024.
[12] BigchainDB. https://www.bigchaindb.com/, 2024.
[13] Brytlyt. https://brytlyt.io/, 2024.
[14] Apache Cassandra. https://cassandra.apache.org, 2024.
[15] The Cassandra Query Language (CQL). https://cassandra.apache.org/doc/latest/cassandra/cql/,2024.
[16] ChatGPT Plugins. https://openai.com/blog/chatgptplugins, March 2024.
[17] Clustrix. https://clustrix.com, 2024.
[18] Apache Arrow DataFusion. https://arrow.apache.org/datafusion/, 2024.
[19] Microsoft DiskANN. https://github.com/microsoft/DiskANN, 2024.
[20] Django Haystack. https://djangohaystack.readthedocs.io, 2024.
[21] Dremio. https://dremio.com/, 2024.
[22] Apache drill. https://drill.apache.org, 2024.
[23] Elasticsearch. https://www.elastic.co, 2024.
[24] FAISS – Facebook AI Similarity Search. https://ai.facebook.com/tools/faiss/, 2024.
[25] Fluree. https://flur.ee/, 2024.
[26] Apache Giraph. https://giraph.apache.org, 2024.
[27] Graphlab. https://en.wikipedia.org/wiki/GraphLab, 2024.
[28] Apache Hbase. https://hbase.apache.org, 2024.
[29] The hdf5 library & file format. https://www.hdfgroup.org/solutions/hdf5, 2024.
[30] Apache Hive. https://hive.apache.org, 2024.
[31] Informix extensions and datablade modules. https://www.ibm.com/docs/en/informix-servers/12.10?topic=informix-extensions-datablade-modules, 2024.
[32] Janusgraph. https://janusgraph.org/, 2024.
[33] Apache Kafka. https://kafka.apache.org/, 2024.
[34] kdb+. https://kx.com/, 2024.
[35] Kinetica. https://www.kinetica.com/, 2024.
[36] LangChain. https://langchain.com, 2024.
[37] LevelDB. https://github.com/google/leveldb, 2024.
[38] Apache Lucene. https://lucene.apache.org, 2024.
[39] Malloy - Experimental Language. https://github.com/looker-open-source/malloy, 2024.
[40] Milvus. https://milvus.io/, 2024.
[41] MongoDB. https://mongodb.com, 2024
[42] Mongodb – querying with sql. https://docs.mongodb.com/datalake/admin/query-with-sql/, 2024.
[43] MySQL – InnoDB Full-Text Indexes. https://dev.mysql.com/doc/refman/8.0/en/innodb-fulltextindex.html, 2024.
[44] Neo4j. https://neo4j.com/, 2024.
[45] Amazon Neptune. https://aws.amazon.com/neptune/, 2024.
[46] Network Common Data Form (NetCDF). https://www.unidata.ucar.edu/software/netcdf/, 2024.
[47] Nuodb. https://nuodb.com, 2024.
[48] Heavydb. https://www.heavy.ai, 2024.
[49] openCypher. https://opencypher.org, 2024.
[50] Oracle graph database. https://www.oracle.com/database/graph/, 2024.
[51] PGQL – Property Graph Query Language. https://pgqllang.org/, 2024.
[52] Oracle Text. https://www.oracle.com/database/technologies/datawarehouse-bigdata/text.html, 2024.
[53] Apache ORC. https://orc.apache.org/, 2024.
[54] Paradigm4 platform overview. https://www.paradigm4.com/technology/scidb-platform-overview/, 2024.
[55] Apache Parquet. https://parquet.apache.org/, 2024.
[56] Partiql – sql-compatible access to relational, semi-structured, and nested data. https://partiql.org/, 2024.
[57] Apache Phoenix. https://phoenix.apache.org, 2024.
[58] Pinecone. https://www.pinecone.io/, 2024.
[59] Apache Pinot. https://pinot.apache.org/, 2024.
[60] PlanetScale. https://planetscale.com/, 2024.
[61] Polars. https://www.pola.rs, 2024.
[62] PostgreSQL – Full Text Search. https://www.postgresql.org/docs/current/textsearch.html,2024.
[63] PrestoDB. https://prestodb.io/, 2024.
[64] PRQL – A Proposal for a Better SQL. https://prqllang.org/, 2024.
[65] Amazon Quantum Ledger Database (QLDB). https://aws.amazon.com/qldb/, 2024.
[66] The rasdaman raster array database. http://www.rasdaman.org, 2024.
[67] Redis. https://redis.io/, 2024.
[68] RocksDB. https://rocksdb.org, 2024.
[69] Singestore. https://www.singlestore.com/, 2024.
[70] Apache Solr. https://solr.apache.org/, 2024.
[71] SQLite. https://www.sqlite.org, 2024.
[72] Sql++ – the next-generation query language for managing json
data. https://www.couchbase.com/sqlplusplus, 2024.
[73] Teradata – creating an array data type. https: //docs.teradata.com/r/S0Fw2AVH8ff3MDA0wDOHlQ/
un3kj~t3qMDO66LF4YXuiw, 2024.
[74] Tigergraph. https://www.tigergraph.com/, 2024.
[75] Tigergraph – gsql. https://www.tigergraph.com/gsql/,
2024.
[76] Tiledb. https://tiledb.com, 2024.
[77] Trino. https://trino.io/, 2024.
[78] Turi. http://turi.com/, 2024.
[79] Vespa. https://vespa.ai/, 2024.
[80] Vitess. https://vitess.io, 2024.
[81] Vitesse Deepgreen DB. https://www.vitessedata.com/
products/deepgreen-db/, 2024.
[82] Project Voldemort. https://www.project-voldemort.com,
2024.
[83] Voltdb. https://www.voltactivedata.com/, 2024.
[84] Weaviate. https://weaviate.io, 2024.
[85] Dbc 1012. https://en.wikipedia.org/wiki/DBC_1012, 2024.
[86] YugabyteDB. https://www.yugabyte.com/, 2024.
[87] D. J. Abadi. Query Execution in Column-Oriented Database Systems. PhD thesis, MIT, 2008.
[88] K. Affolter, K. Stockinger, and A. Bernstein. A comparative survey of recent natural language interfaces for databases. VLDB J., 28(5):793–819, 2019. doi: 10.1007/s00778-019-00567-8.
[89] H. Ahmadi. In-memory query execution in google bigquery. https://cloud.google.com/blog/products/bigquery/inmemory-query-execution-in-google-bigquery, Aug 2016.
[90] A. Ailamaki, D. J. DeWitt, M. D. Hill, and M. Skounakis. Weaving relations for cache performance. In VLDB, volume 1, pages 169–180, 2001.
[91] G. Anadiotis. Open source postgresql on steroids: Swarm64 database acceleration software for performance improvement and analytics. https://www.zdnet.com/article/opensource-postgresql-on-steroids-swarm64-databaseacceleration-software-for-performance-improvementand-analytics/, apr 2023.
[92] M. Armbrust, T. Das, L. Sun, B. Yavuz, S. Zhu, M. Murthy, J. Torres, H. van Hovell, A. Ionescu, A. Łuszczak, et al. Delta lake: high-performance acid table storage over cloud object stores. Proceedings of the VLDB Endowment, 13(12):3411– 3424, 2020.
[93] M. Armbrust, A. Ghodsi, R. Xin, and M. Zaharia. Lakehouse: a new generation of open platforms that unify data warehousing and advanced analytics. In Proceedings of CIDR, page 8, 2021.
[94] N. Armenatzoglou, S. Basu, N. Bhanoori, M. Cai, N. Chainani, K. Chinta, V. Govindaraju, T. J. Green, M. Gupta, S. Hillig, E. Hotinger, Y. Leshinksy, J. Liang, M. McCreedy, F. Nagel, I. Pandis, P. Parchas, R. Pathak, O. Polychroniou, F. Rahman, G. Saxena, G. Soundararajan, S. Subramanian, and D. Terry. Amazon redshift re-invented. In Proceedings of the 2022 International Conference on Management of Data, SIGMOD ’22, pages 2205–2217, 2022. doi: 10.1145/3514221.3526045.
[95] M. Aslett. How will the database incumbents respond to NoSQL and NewSQL? The 451 Group, April 2011.
[96] M. Aslett. Ten years of NewSQL: Back to the future of distributed relational databases. The 451 Group, June 2021.
[97] S. Babu and P. Bizarro. Adaptive query processing in the looking glass. In CIDR, pages 238–249, January 2005.
[98] D. F. Bacon, N. Bales, N. Bruno, B. F. Cooper, A. Dickinson, A. Fikes, C. Fraser, A. Gubarev, M. Joshi, E. Kogan, A. Lloyd, S. Melnik, R. Rao, D. Shue, C. Taylor, M. van der Holst, and D. Woodford. Spanner: Becoming a sql system. In Proceedings of the 2017 ACM International Conference on Management of Data, SIGMOD ’17, pages 331–343, 2017. doi: 10.1145/3035918.3056103.
[99] J. Baker, C. Bond, J. C. Corbett, J. Furman, A. Khorlin, J. Larson, J.-M. Leon, Y. Li, A. Lloyd, and V. Yushprakh. Megastore: Providing scalable, highly available storage for interactive services. In Proceedings of the Conference on Innovative Data system Research (CIDR), pages 223–234, 2011.
[100] N. Bakibayev, D. Olteanu, and J. Závodný. Fdb: A query engine for factorised relational databases. Proc. VLDB Endow., 5
(11):1232–1243, jul 2012. doi: 10.14778/2350229.2350242.
[101] S. Banon. Amazon: NOT OK - why we had to change Elastic licensing. https://www.elastic.co/blog/why-licensechange-aws, jan 2021.
[102] J. Barr. AQUA (Advanced Query Accelerator) – A Speed Boost for Your Amazon Redshift Queries. https://aws.amazon.com/blogs/aws/new-aqua-advancedquery-accelerator-for-amazon-redshift/, Apr 2021.
[103] P. Baumann. A database array algebra for spatio-temporal data and beyond. In Next Generation Information Technologies and Systems, 4th International Workshop, NGITS’99, volume 1649 of Lecture Notes in Computer Science, pages 76–93, 1999. doi: 10.1007/3-540-48521-X_7.
[104] E. Begoli, J. Camacho-Rodríguez, J. Hyde, M. J. Mior, and D. Lemire. Apache calcite: A foundational framework for optimized query processing over heterogeneous data sources. In Proceedings of the 2018 International Conference on Management of Data, SIGMOD ’18, pages 221–230, 2018. doi: 10.1145/3183713.3190662.
[105] A. Behm, S. Palkar, U. Agarwal, T. Armstrong, D. Cashman, A. Dave, T. Greenstein, S. Hovsepian, R. Johnson, A. Sai Krishnan, P. Leventis, A. Luszczak, P. Menon, M. Mokhtar, G. Pang, S. Paranjpye, G. Rahn, B. Samwel, T. van Bussel, H. van Hovell, M. Xue, R. Xin, and M. Zaharia. Photon: A fast query engine for lakehouse systems. In Proceedings of the 2022 International Conference on Management of Data, SIGMOD ’22, pages 2326–2339, 2022. doi: 10.1145/3514221.3526054.
[106] P. A. Boncz, M. Zukowski, and N. Nes. Monetdb/x100: Hyperpipelining query execution. In CIDR, pages 225–237, 2005.
[107] H. Boral and D. J. DeWitt. Database machines: An idea whose time passed? A critique of the future of database machines. pages 166–187, 1983. doi: 10.1007/978-3-642 69419-6\_10.
[108] T. Bray. AWS and Blockchain. https://www.tbray.org/ ongoing/When/202x/2022/11/19/AWS-Blockchain, nov 2019.
[109] P. Carbone, A. Katsifodimos, S. Ewen, V. Markl, S. Haridi, and K. Tzoumas. Apache flink: Stream and batch processing in a single engine. The Bulletin of the Technical Committee on Data Engineering, 38(4), 2015.
[110] R. Cattell. Scalable sql and nosql data stores. SIGMOD Rec., 39:12–27, 2011.
[111] F. Chang, J. Dean, S. Ghemawat, W. C. Hsieh, D. A. Wallach,
M. Burrows, T. Chandra, A. Fikes, and R. E. Gruber. Bigtable:
A distributed storage system for structured data. In Proceedings of the USENIX Symposium on Operating Systems Design and Implementation, OSDI ’06, pages 205–218, 2006.
[112] S. Chaudhuri and G. Weikum. Rethinking database system architecture: Towards a self-tuning risc-style database system. In VLDB 2000, Proceedings of 26th International Conference on Very Large Data Bases, pages 1–10, 2000.
[113] C. Chin. The rise and fall of the olap cube. https: //www.holistics.io/blog/the-rise-and-fall-of-theolap-cube/, January 2020.
[114] M. Chock, A. F. Cardenas, and A. Klinger. Database structure and manipulation capabilities of a picture database management system (picdms). IEEE Transactions on Pattern Analysis and Machine Intelligence, PAMI-6(4):484–492, 1984. doi: 10.1109/TPAMI.1984.4767553.
[115] E. F. Codd. A relational model of data for large shared
data banks. Commun. ACM, 13(6):377–387, jun 1970. doi: 10.1145/362384.362685.
[116] E. F. Codd. Further normalization of the data base relational
model. Research Report / RJ / IBM / San Jose, California, RJ909, 1971.
[117] W. W. W. Consortium. Overview of sgml resources. https: //www.w3.org/MarkUp/SGML/, 2004.
[118] W. W. W. Consortium. Extensible Markup Language (XML). https://www.w3.org/XML/, 2016.
[119] J. C. Corbett, J. Dean, M. Epstein, A. Fikes, C. Frost, J. Furman, S. Ghemawat, A. Gubarev, C. Heiser, P. Hochschild, W. Hsieh, S. Kanthak, E. Kogan, H. Li, A. Lloyd, S. Melnik, D. Mwaura, D. Nagle, S. Quinlan, R. Rao, L. Rolig, M. S. Yasushi Saito, C. Taylor, R. Wang, and D. Woodford. Spanner: Google’s Globally-Distributed Database. In OSDI, 2012.
[120] A. Crotty, V. Leis, and A. Pavlo. Are you sure you want to use MMAP in your database management system? In Conference on Innovative Data Systems Research. www.cidrdb.org, 2022.
[121] B. Dageville, T. Cruanes, M. Zukowski, V. Antonov, A. Avanes, J. Bock, J. Claybaugh, D. Engovatov, M. Hentschel, J. Huang, A. W. Lee, A. Motivala, A. Q. Munir, S. Pelley, P. Povinec, G. Rahn, S. Triantafyllis, and P. Unterbrunner. The snowflake elastic data warehouse. In Proceedings of the 2016 International Conference on Management of Data, SIGMOD ’16, pages 215–226, 2016. doi: 10.1145/2882903.2903741.
[122] J. Dean and S. Ghemawat. MapReduce: Simplified data processing on large clusters. In 6th Symposium on Operating Systems Design & Implementation (OSDI 04). USENIX Association, Dec. 2004.
[123] J. Dean and S. Ghemawat. Mapreduce: A flexible data processing tool. Commun. ACM, 53(1):72–77, Jan. 2010.
[124] A. Dearmer. Storing apache hadoop data on the cloud - hdfs
vs. s3. https://www.xplenty.com/blog/storing-apachehadoop-data-cloud-hdfs-vs-s3/, November 2019.
[125] G. DeCandia, D. Hastorun, M. Jampani, G. Kakulapati, A. Lakshman, A. Pilchin, S. Sivasubramanian, P. Vosshall, and W. Vogels. Dynamo: Amazon’s highly available key-value store. SIGOPS Oper. Syst. Rev., 41(6):205–220, oct 2007.
[126] A. Deutsch, N. Francis, A. Green, K. Hare, B. Li, L. Libkin, T. Lindaaker, V. Marsault, W. Martens, J. Michels, F. Murlak, S. Plantikow, P. Selmer, O. van Rest, H. Voigt, D. Vrgoc,ˇ
M. Wu, and F. Zemke. Graph pattern matching in gql and sql/pgq. In Proceedings of the 2022 International Conference on Management of Data, SIGMOD ’22, pages 2246–2258, 2022. doi: 10.1145/3514221.3526057.
[127] D. DeWitt and J. Gray. Parallel database systems: The future of high performance database systems. Commun. ACM, 35(6): 85–98, jun 1992. doi: 10.1145/129888.129894.
[128] C. Diaconu, C. Freedman, E. Ismert, P. Larson, P. Mittal, R. Stonecipher, N. Verma, and M. Zwilling. Hekaton:
SQL server’s memory-optimized OLTP engine. In Proceedings of the ACM SIGMOD International Conference on Management of Data, pages 1243–1254, 2013. doi: 10.1145/
2463676.2463710.
[129] M. Elhemali, N. Gallagher, N. Gordon, J. Idziorek, R. Krog, C. Lazier, E. Mo, A. Mritunjai, S. Perianayagam, T. Rath, S. Sivasubramanian, J. C. S. III, S. Sosothikul, D. Terry, and A. Vig. Amazon DynamoDB: A scalable, predictably performant, and fully managed NoSQL database service. In USENIX
Annual Technical Conference, pages 1037–1048, July 2022.
[130] J. Fan, A. G. S. Raj, and J. M. Patel. The case against specialized graph analytics engines. In Seventh Biennial Conference on Innovative Data Systems Research, CIDR, 2015.
[131] B. Fitzpatrick. Distributed caching with memcached. Linux J., 2004(124):5, aug 2004. ISSN 1075–3583.
[132] M. Freitag, M. Bandle, T. Schmidt, A. Kemper, and T. Neumann. Adopting worst-case optimal joins in relational database
systems. Proc. VLDB Endow., 13(12):1891–1904, jul 2020.
doi: 10.14778/3407790.3407797.
[133] H. Fu, C. Liu, B. Wu, F. Li, J. Tan, and J. Sun. Catsql: Towards real world natural language to sql applications. Proc. VLDB Endow., 16(6):1534–1547, feb 2023. doi: 10.14778/
3583140.3583165.
[134] S. Ghemawat, H. Gobioff, and S.-T. Leung. The google file system. SIGOPS Oper. Syst. Rev., 37(5):29–43, oct 2003. ISSN 0163-5980. doi: 10.1145/1165389.945450.
[135] J. Gray, A. Bosworth, A. Layman, and H. Pirahesh. Data
cube: A relational aggregation operator generalizing group-by, cross-tab, and sub-total. In Proceedings of the International Conference on Data Engineering, pages 152–159, 1996. doi: 10.1109/ICDE.1996.492099.
[136] S. Gupta, S. Rahnama, J. Hellings, and M. Sadoghi. Resilientdb: Global scale resilient blockchain fabric. Proc. VLDB Endow., 13(6):868–883, 2020. doi: 10.14778/
3380750.3380757.
[137] E. Hanson and A. Comet. Why Your Vector Database Should Not be a Vector Database. https://www.singlestore.com/blog/why-your-vector-database-should-not-be-avector-database/, April 2023.
[138] G. Harrison. How WiredTiger Revolutionized MongoDB. https://www.dbta.com/Columns/MongoDB-Matters/HowWiredTiger-Revolutionized-MongoDB-145510.aspx, mar
2021.
[139] G. G. Hendrix, E. D. Sacerdoti, D. Sagalowicz, and J. Slocum. Developing a natural language interface to complex data. ACM Trans. Database Syst., 3(2):105–147, jun 1978. doi: 10.1145/ 320251.320253.
[140] Y. Huai, A. Chauhan, A. Gates, G. Hagleitner, E. N. Hanson, O. O’Malley, J. Pandey, Y. Yuan, R. Lee, and X. Zhang. Major technical advancements in apache hive. In Proceedings of the 2014 ACM SIGMOD international conference on Management of data, pages 1235–1246, 2014.
[141] D. Huang, Q. Liu, Q. Cui, Z. Fang, X. Ma, F. Xu, L. Shen, L. Tang, Y. Zhou, M. Huang, W. Wei, C. Liu, J. Zhang, J. Li, X. Wu, L. Song, R. Sun, S. Yu, L. Zhao, N. Cameron, L. Pei, and X. Tang. Tidb: A raft-based htap database. Proc.
VLDB Endow., 13(12):3072–3084, aug 2020. doi: 10.14778/ 3415478.3415535.
[142] K. E. Iverson. A Programming Language. John Wiley & Sons, Inc., 1962. ISBN 0471430145.
[143] A. Jindal, S. Madden, M. Castellanos, and M. Hsu. Graph analytics using vertica relational database. In 2015 IEEE International Conference on Big Data, pages 1191–1200, 2015.
[144] R. Kallman, H. Kimura, J. Natkins, A. Pavlo, A. Rasin, S. Zdonik, E. P. C. Jones, S. Madden, M. Stonebraker, Y. Zhang, J. Hugg, and D. J. Abadi. H-store: A high-performance, distributed main memory transaction processing system. Proc. VLDB Endow., 1(2):1496–1499, aug 2008. doi: 10.14778/1454159.1454211.
[145] A. Kane. pgvector. https://github.com/pgvector/pgvector, 2024.
[146] A. Kemper and T. Neumann. Hyper: A hybrid oltp&olap main memory database system based on virtual memory snapshots. In Proceedings of the 27th International Conference on Data Engineering, pages 195–206. IEEE Computer Society, 2011. doi: 10.1109/ICDE.2011.5767867.
[147] T. Kersten, V. Leis, A. Kemper, T. Neumann, A. Pavlo, and P. Boncz. Everything you always wanted to know about compiled and vectorized queries but were afraid to ask. Proc. VLDB Endow., 11(13):2209–2222, jan 2019. doi: 10.14778/3275366.3284966.
[148] R. Kimball. The Data Warehouse Toolkit: Practical Techniques for Building Dimensional Data Warehouses. John Wiley, 1996.
[149] R. Kimball and K. Strehlo. Why decision support fails and how to fix it. SIGMOD Rec., 24(3):92–97, 1995.
[150] M. Kornacker, A. Behm, V. Bittorf, T. Bobrovytsky, C. Ching, A. Choi, J. Erickson, M. Grund, D. Hecht, M. Jacobs, I. Joshi, L. Kuff, D. Kumar, A. Leblang, N. Li, I. Pandis, H. Robinson, D. Rorke, S. Rus, J. Russell, D. Tsirogiannis, S. WandermanMilne, and M. Yoder. Impala: A modern, open-source sql engine for hadoop. In CIDR, 2015.
[151] T. Kraska, A. Beutel, E. H. Chi, J. Dean, and N. Polyzotis. The case for learned index structures. In Proceedings of the 2018 International Conference on Management of Data, SIGMOD’18, pages 489–504, 2018. doi: 10.1145/3183713.3196909.
[152] S. Krishnan, Z. Yang, K. Goldberg, J. Hellerstein, and I. Stoica. Learning to optimize join queries with deep reinforcement learning, 2018. URL https://arxiv.org/abs/1808.03196.
[153] F. Lardinois. Aws gives open source the middle finger. https://techcrunch.com/2019/01/09/aws-gives-opensource-the-middle-finger/, jan 2019.
[154] V. Leis, A. Gubichev, A. Mirchev, P. A. Boncz, A. Kemper, and T. Neumann. How good are query optimizers, really? Proc. VLDB Endow., 9(3):204–215, 2015. doi: 10.14778/2850583.2850594.
[155] D. Maier and B. Vance. A call to order. In Proceedings
of the Twelfth ACM SIGACT-SIGMOD-SIGART Symposium on Principles of Database Systems, pages 1–16, 1993. doi: 10.1145/153850.153851.
[156] R. Marcus, P. Negi, H. Mao, N. Tatbul, M. Alizadeh, and T. Kraska. Bao: Making learned query optimization practical.
In Proceedings of the 2021 International Conference on Management of Data, SIGMOD ’21, pages 1275–1288, 2021. doi: 10.1145/3448016.3452838.
[157] D. McDiarmid. Vector search with clickhouse. https://clickhouse.com/blog/vector-search-clickhouse-p2, May 2023.
[158] C. McDonnell. The graph-relational database, defined. https://www.edgedb.com/blog/the-graph-relationaldatabase-defined, March 2022.
[159] W. McKinney et al. Data structures for statistical computing
in python. In Proceedings of the 9th Python in Science Conference, volume 445, pages 51–56, 2010.
[160] F. McSherry. Scalability! but at what cost? http://www.frankmcsherry.org/graph/scalability/cost/2015/01/15/COST.html, January 2015.
[161] S. Melnik, A. Gubarev, J. J. Long, G. Romer, S. Shivakumar, M. Tolton, and T. Vassilakis. Dremel: Interactive analysis of web-scale datasets. Proc. VLDB Endow., 3(12):330–339, sep 2010. ISSN 2150-8097. doi: 10.14778/1920841.1920886.
[162] S. Melnik, A. Gubarev, J. J. Long, G. Romer, S. Shivakumar, M. Tolton, T. Vassilakis, H. Ahmadi, D. Delorey, S. Min, M. Pasumansky, and J. Shute. Dremel: A decade of interactive sql analysis at web scale. Proc. VLDB Endow., 13(12):3461–3472, aug 2020. ISSN 2150-8097. doi: 10.14778/3415478.3415568.
[163] P. Menon, A. Ngom, T. C. Mowry, A. Pavlo, and L. Ma. Permutable compiled queries: Dynamically adapting compiled queries without recompiling. Proc. VLDB Endow., 14(2):101– 113, 2020. doi: 10.14778/3425879.3425882.
[164] C. Metz. Google search index splits with mapreduce. https://www.theregister.com/2010/09/09/google_caffeine_explained/, September 2010.
[165] J. Michels, K. Hare, K. Kulkarni, C. Zuzarte, Z. H. Liu, B. Hammerschmidt, and F. Zemke. The new and improved sql: 2016 standard. SIGMOD Rec., 47(2):51–60, dec 2018. doi: 10.1145/3299887.3299897.
[166] D. Misev and P. Baumann. Sql support for multidimensional arrays. Technical Report 34, Jacobs University, July
2017. URL https://nbn-resolving.org/urn:nbn:de:gbv: 579-opus-1007237.
[167] F. Nargesian, E. Zhu, R. J. Miller, K. Q. Pu, and P. C. Arocena. Data lake management: Challenges and opportunities. Proc. VLDB Endow., 12(12):1986–1989, aug 2019. doi: 10.14778/ 3352063.3352116.
[168] H. Q. Ngo, C. Ré, and A. Rudra. Skew strikes back: New developments in the theory of join algorithms. SIGMOD Rec., 42(4):5–16, feb 2014. doi: 10.1145/2590989.2590991.
[169] NVIDIA, P. Vingelmann, and F. H. Fitzek. Cuda toolkit. https: //developer.nvidia.com/cuda-toolkit, 2020.
[170] M. A. Olson, K. Bostic, and M. I. Seltzer. Berkeley DB. In Proceedings of the FREENIX Track: 1999 USENIX Annual Technical Conference, pages 183–191, 1999.
[171] A. Pavlo and M. Aslett. What’s really new with newsql? SIGMOD Record, 45(2):45–55, Sep 2016.
[172] A. Pavlo, E. Paulson, A. Rasin, D. J. Abadi, D. J. DeWitt, S. Madden, and M. Stonebraker. A comparison of approaches to large-scale data analysis. In Proceedings of the ACM SIGMOD International Conference on Management of Data, pages 165–178, 2009.
[173] A. Pavlo, G. Angulo, J. Arulraj, H. Lin, J. Lin, L. Ma, P. Menon, T. Mowry, M. Perron, I. Quah, S. Santurkar, A. Tomasic, S. Toor, D. V. Aken, Z. Wang, Y. Wu, R. Xian, and T. Zhang. Self-driving database management systems. In CIDR 2017, Conference on Innovative Data Systems Research, 2017.
[174] A. Pavlo, M. Butrovich, A. Joshi, L. Ma, P. Menon, D. V. Aken, L. Lee, and R. Salakhutdinov. External vs. internal: An essay on machine learning agents for autonomous database management systems. IEEE Data Eng. Bull., 42(2):32–46, 2019.
[175] P. Pedreira, O. Erling, M. Basmanova, K. Wilfong, L. Sakka, K. Pai, W. He, and B. Chattopadhyay. Velox: Meta’s unified execution engine. Proc. VLDB Endow., 15(12):3372–3384, aug 2022. doi: 10.14778/3554821.3554829.
[176] P. Pedreira, O. Erling, K. Karanasos, S. Schneider, W. McKinney, S. R. Valluri, M. Zait, and J. Nadeau. The composable data management system manifesto. Proc. VLDB Endow., 16 (10):2679–2685, jun 2023. doi: 10.14778/3603581.3603604.
[177] D. Petersohn, S. Macke, D. Xin, W. Ma, D. Lee, X. Mo, J. E. Gonzalez, J. M. Hellerstein, A. D. Joseph, and A. Parameswaran. Towards scalable dataframe systems. Proc.
VLDB Endow., 13(12):2033–2046, jul 2020. doi: 10.14778/3407790.3407807.
[178] D. Petkovic. SQL/JSON standard: Properties and deficiencies. Datenbank-Spektrum, 17(3):277–287, 2017. doi: 10.1007/ s13222-017-0267-4.
[179] D. Pritchett. BASE: An Acid Alternative: In Partitioned Databases, Trading Some Consistency for Availability Can Lead to Dramatic Improvements in Scalability. ACM Queue,
6(3):48–55, may 2008. doi: 10.1145/1394127.1394128.
[180] M. Raasveldt and H. Mühleisen. Duckdb: An embeddable analytical database. In Proceedings of the 2019 International Conference on Management of Data, SIGMOD ’19, pages 1981– 1984, 2019. doi: 10.1145/3299869.3320212.
[181] M. Rocklin. Dask: Parallel computation with blocked algorithms and task scheduling. In Proceedings of the 14th Python in Science Conference, pages 130–136, 2015.
[182] F. Rusu. Multidimensional array data management. Found.
Trends Databases, 12(2-3):69–220, 2023. doi: 10.1561/ 1900000069.
[183] S. Sakr, A. Bonifati, H. Voigt, A. Iosup, K. Ammar, R. Angles, W. Aref, M. Arenas, M. Besta, P. A. Boncz, K. Daudjee, E. D. Valle, S. Dumbrava, O. Hartig, B. Haslhofer, T. Hegeman, J. Hidders, K. Hose, A. Iamnitchi, V. Kalavri, H. Kapp, W. Martens, M. T. Özsu, E. Peukert, S. Plantikow, M. Ragab, M. R. Ripeanu, S. Salihoglu, C. Schulz, P. Selmer, J. F. Sequeda, J. Shinavier, G. Szárnyas, R. Tommasini, A. Tumeo, A. Uta, A. L. Varbanescu, H.-Y. Wu, N. Yakovets, D. Yan, and E. Yoneki. The future is big graphs: A community view on graph processing systems. Commun. ACM, 64(9):62–71, aug 2021. doi: 10.1145/3434642.
[184] G. Salton and M. E. Lesk. The smart automatic document retrieval systems–an illustration. Commun. ACM, 8(6):391–398, jun 1965. doi: 10.1145/364955.364990.
[185] R. Sethi, M. Traverso, D. Sundstrom, D. Phillips, W. Xie, Y. Sun, N. Yegitbasi, H. Jin, E. Hwang, N. Shingte, and
C. Berner. Presto: Sql on everything. In 2019 IEEE 35th International Conference on Data Engineering (ICDE), pages 1802–1813, 2019. doi: 10.1109/ICDE.2019.00196.
[186] M. A. Soliman, L. Antova, V. Raghavan, A. El-Helw, Z. Gu, E. Shen, G. C. Caragea, C. Garcia-Alvarado, F. Rahman, M. Petropoulos, F. Waas, S. Narayanan, K. Krikellas, and R. Baldwin. Orca: a modular query optimizer architecture for big data. In Proceedings of the 2014 ACM SIGMOD International Conference on Management of Data, SIGMOD ’14, pages 337–348, 2014. doi: 10.1145/2588555.2595637.
[187] M. Stonebraker. The case for polystores. https:// wp.sigmod.org/?p=1629, 2015.
[188] M. Stonebraker and J. Hellerstein. Readings in Database Systems, chapter What Goes Around Comes Around, pages 2–41. 4th edition, 2005.
[189] M. Stonebraker, S. Madden, D. J. Abadi, S. Harizopoulos, N. Hachem, and P. Helland. The end of an architectural era: (it’s time for a complete rewrite). In Proceedings of the 33rd International Conference on Very Large Data Bases, VLDB ’07, pages 1150–1160. VLDB Endowment, 2007.
[190] M. Stonebraker, D. Abadi, D. J. DeWitt, S. Madden, E. Paulson, A. Pavlo, and A. Rasin. Mapreduce and parallel dbmss: Friends or foes? Commun. ACM, 53(1):64–71, Jan. 2010.
[191] M. Stonebraker, P. Brown, A. Poliakov, and S. Raman. The architecture of scidb. In Scientific and Statistical Database Management - 23rd International Conference, SSDBM 2011, volume 6809 of Lecture Notes in Computer Science, pages 1–16. Springer, 2011. doi: 10.1007/978-3-642-22351-8\_1.
[192] L. Sullivan. Performance issues in mid-sized relational
database machines. Master’s thesis, Rochester Institute of Technology, 1989.
[193] Z. Sun, X. Zhou, and G. Li. Learned index: A comprehensive experimental evaluation. Proc. VLDB Endow., 16(8):1992–2004, apr 2023. doi: 10.14778/3594512.3594528.
[194] Y. Sverdlik. Google dumps mapreduce in favor of new hyper-scale analytics system. https:
//www.datacenterknowledge.com/archives/2014/06/25/google-dumps-mapreduce-favor-new-hyper-scaleanalytics-system, June 2014.
[195] R. Taft, I. Sharif, A. Matei, N. VanBenschoten, J. Lewis,
T. Grieger, K. Niemi, A. Woods, A. Birzin, R. Poss, P. Bardea, A. Ranade, B. Darnell, B. Gruneir, J. Jaffray, L. Zhang, and P. Mattis. Cockroachdb: The resilient geo-distributed SQL database. In Proceedings of the 2020 International Conference on Management of Data, SIGMOD, pages 1493–1509, 2020. doi: 10.1145/3318464.3386134.
[196] D. ten Wolde, T. Singh, G. Szarnyas, and P. Boncz. Duckpgq: Efficient property graph queries in an analytical rdbms. In CIDR, 2023. URL https://www.cidrdb.org/cidr2023/papers/p66-wolde.pdf.
[197] A. Thusoo, J. S. Sarma, N. Jain, Z. Shao, P. Chakka, N. Zhang, S. Antony, H. Liu, and R. Murthy. Hive - a petabyte scale data warehouse using hadoop. In International Conference on Data Engineering (ICDE 2010), pages 996–1005, 2010. doi:10.1109/ICDE.2010.5447738.
[198] E. Totoni, T. A. Anderson, and T. Shpeisman. HPAT: high performance analytics with scripting ease-of-use. In Proceedings of the International Conference on Supercomputing, pages 9:1–9:10, 2017. doi: 10.1145/3079079.3079099.
[199] T. Trautmann. Understanding the document-relational database. https://fauna.com/blog/what-is-a-documentrelational-database, September 2021.
[200] D. Van Aken, A. Pavlo, G. J. Gordon, and B. Zhang. Automatic database management system tuning through large-scale machine learning. In Proceedings of the 2017 ACM International Conference on Management of Data, SIGMOD ’17, pages 1009–1024, 2017. doi: 10.1145/3035918.3064029.
[201] M. Zaharia, R. S. Xin, P. Wendell, T. Das, M. Armbrust, A. Dave, X. Meng, J. Rosen, S. Venkataraman, M. J. Franklin, A. Ghodsi, J. Gonzalez, S. Shenker, and I. Stoica. Apache
spark: a unified engine for big data processing. Commun. ACM, 59(11):56–65, oct 2016. doi: 10.1145/2934664.
[202] C. Zaniolo. The database language GEM. In SIGMOD, pages 207–218, 1983.
[203] X. Zeng, Y. Hui, J. Shen, A. Pavlo, W. McKinney, and H. Zhang. An empirical evaluation of columnar storage formats. Proc. VLDB Endow., 17(2):148–161, 2023. URL https:
//www.vldb.org/pvldb/vol17/p148-zeng.pdf.
[204] X. Zhang, Z. Chang, Y. Li, H. Wu, J. Tan, F. Li, and B. Cui. Facilitating database tuning with hyper-parameter optimization: a comprehensive experimental evaluation. Proc. VLDB Endow., 15(9):1808–1821, may 2022. doi: 10.14778/3538598.3538604.