Эндрю Бруст, директор Blue Badge Insights, представил на портале The New Stack обзор основных тенденций развития баз данных в 2024 г. — таких как векторное хранилище, GraphQL и открытые форматы таблиц (open table formats, OTF) — и то, что они предвещают в 2025 г.
Для баз данных
И, конечно, развитие искусственного интеллекта еще ярче высветило важность точности и гигиены данных, чтобы создавать точные, адаптированные модели ИИ и контекстные подсказки. Ключевую роль в управлении всем этим играют СУБД, будь то реляционные, NoSQL, мультимодельные, специализированные, операционные или аналитические.
В 2025 г. значение баз данных будет продолжать расти, и это не прекратится и в дальнейшем. Даже если сегодняшние СУБД в конечном итоге будут вытеснены, потребность в категории платформ, оптимизирующих хранение и извлечение данных, сохранится, поскольку они являются необходимой инфраструктурой для интеллектуальных систем, обладающих высокой ценностью.
Надо понимать, что в «данных» нет ничего волшебного или неземного. Это просто записи событий, которые произошли в определенный момент времени, будь то изменения температуры, совершенные покупки, переходы по ссылкам или повышения или понижения уровня запасов. Данные — это просто отражение всех людей, организаций, машин и процессов в мире. Отслеживание текущего, прошлого и ожидаемого будущего состояния всех этих объектов, чем и занимаются СУБД, является непреходящей потребностью.
Самые мощные платформы баз данных существуют уже несколько десятилетий и достигли этого долголетия благодаря внедрению новых функций, отражающих окружающий мир технологий, оставаясь при этом верными своей основной задаче — хранить данные и выполнять запросы к ним с максимально возможной производительностью.
Десятилетия назад уже было очевидно, что все программные приложения для бизнеса являются также приложениями баз данных, и сегодня это не менее верно. Но теперь эта истина вышла за рамки приложений и включает в себя встраиваемое ПО на периферии для IoT, API в облаке для сервисов и SaaS-предложений, а также специальную облачную инфраструктуру для получения выводов и поиска информации с помощью ИИ.
«What’s Our Vector, Victor?»
Одним из важных изменений последнего времени, которое будет продолжаться и в 2025 г., является использование баз данных для хранения так называемых «векторов». Вектор — это числовое представление чего-то сложного. В физике вектор может быть просто величиной, сопряженной с направлением. В мире науки о данных вектор может быть конкатенированным кодированием значений характеристик модели машинного обучения. В мире генеративного ИИ (GenAI) сложные сущности, представленные векторами, включают семантику и содержание документов, изображений, аудио- и видеофайлов или их фрагментов («chunks»).
Важной тенденцией, начавшейся в прошлые годы, но набравшей значительные обороты в
Это выходит за рамки обычной практики в области операционных баз данных, когда игроки расширяют их функциональность. В данном случае это конкурентный ход, направленный на противодействие поставщикам векторных баз данных, таким как Pinecone, Zilliz, Weaviate и др. Крупные платформы баз данных, включая Microsoft SQL Server, Oracle Database, PostgreSQL и MySQL с реляционной стороны и MongoDB, DataStax/Apache Cassandra, Microsoft Cosmos DB и Amazon DocumentDB/DynamoDB с NoSQL/мультимодельной стороны, расширили свои платформы векторными возможностями.
Эти возможности обычно начинаются с добавления нескольких функций в SQL-диалект платформы для определения расстояния между векторами, а затем расширяются до поддержки нативного типа данных VECTOR, включая строковые и двоичные реализации. Многие платформы также добавляют явную поддержку шаблона программирования RAG (retrieval augmented generation, генерация с расширенной выборкой), который использует векторы для контекстуализации подсказок, отправляемых большим языковым моделям (LLM).
Как это отразится на специализированных векторных базах данных? Трудно сказать. Хотя эти платформы будут делать акцент на своих более совершенных функциях, традиционные игроки укажут на то, что использование их платформ для векторного хранения и поиска поможет избежать сложностей, которые может повлечь за собой внедрение дополнительной специализированной платформы базы данных.
GenAI для разработчиков и аналитиков
Векторные возможности — не единственная точка соприкосновения между СУБД и GenAI. Иногда влияние ИИ сказывается не на самой базе данных, а на инструментарии вокруг нее. В этой области крупнейшей технологией на стыке баз данных и GenAI является ряд интерфейсов для преобразования естественного языка в SQL. Возможность запросить базу данных с помощью естественного языка сейчас настолько распространена, что стала «ключевой». Но здесь еще много места для инноваций.
Например, Microsoft предоставляет не просто чат-бот для генерации SQL-запросов, но и позволяет встроенным комментариям в SQL-скрипте функционировать как GenAI-подсказки, которые могут генерировать целые блоки кода. Также предусмотрена функция завершения кода, которая всплывает на лету прямо во время составления кода.
С точки зрения аналитики технология Microsoft Fabric Copilot помогает в блокнотах, конвейерах, потоках данных, активах аналитики реального времени, хранилищах данных и Power BI, как для отчетов, так и для DAX-запросов (Data Analysis eXpressions, специализированный язык запросов Microsoft для Power BI и табличного режима SQL Server Analysis Services). По мнению многих (включая автора данной статьи), писать на нем невероятно сложно, а технология GenAI делает эту практику гораздо более доступной.
К слову о BI: аналитические базы данных тоже имеют отношение к ИИ. Так, в июле 2024 г. OpenAI приобрела компанию Rockset, которая имеет одну из таких платформ, основанную на Open Source-проекте RocksDB, чтобы ускорить работу своей платформы по поиску информации. Snowflake, платформа на основе реляционного облачного хранилища данных, также поддерживает нативный тип VECTOR и функции векторного сходства, а ее поисковый механизм Cortex Search обеспечивает операции векторного поиска. Snowflake также поддерживает шесть различных моделей встраивания ИИ непосредственно в рамках своей платформы. Векторные вложения поддерживают и другие платформы для хранилищ данных, в том числе Google BigQuery. Компания Databricks, работающая в области озер-хранилищ (lakehouse) данных, также участвует в векторной игре.
«OLxP»
Продолжая рассматривать аналитические базы данных, надо отметить еще одну тенденцию 2025 г. — объединение аналитических и операционных баз данных. Такое слияние OLTP (онлайновой обработки транзакций в реальном времени) и OLAP (оперативной аналитической обработки) иногда называют операционной аналитикой. Она также получила такие названия, как «транслитическая» («translytical») и HTAP (гибридная транзакционно-аналитическая обработка).
Как бы вы ее ни называли, многие вендоры поддерживают эту идею. В их число входят SAP, чья платформа HANA была создана на ее основе, и SingleStore, само название которой (переименована из MemSQL в 2020 г.) указывает на способность платформы работать с обеими системами. Функции Unistore и Hybrid Tables от Snowflake также предназначены для этого сценария использования. Онлайн-таблицы Databricks также используют структуру rowstore (данные, логически упорядоченные в виде таблицы, состоящей из строк и столбцов, физически хранятся в формате строк), хотя они предназначены для операций хранения признаков (feature store) и векторов, а не для OLTP.
Однако не все в восторге от этой концепции. Например, в сентябре 2024 г. MongoDB объявила, что ее функция Atlas Data Lake, которая так и не вышла из предварительной версии, снимается с разработки. Однако MongoDB, похоже, является единственным оппонентом в этом вопросе.
API данных и мобильность
Это не единственная область, где MongoDB отступила с территории, на которую устремились другие. Компания также объявила об отказе от своего API Atlas GraphQL. Тем временем Oracle REST Data Services (ORDS), Microsoft Database API Builder и AWS AppSync добавили возможности GraphQL в Oracle Autonomous Database/Oracle 23ai, Microsoft Azure SQL Database/Cosmos DB/SQL Database for Postgres и Amazon DynamoDB/Aurora/RDS, соответственно.
А как насчет мобильных баз данных? В свое время они были основным направлением для Couchbase, для Microsoft и для MongoDB с ее платформой Atlas Device SDKs/Realm. Couchbase Mobile все еще существует, но Microsoft Azure SQL Edge, по крайней мере номинально, смещает фокус компании в сторону IoT, а MongoDB официально отказалась от Atlas Realm, своих Device SDK и Device Sync (хотя мобильная база данных для устройств продолжит существовать в виде Open Source-проекта). Похоже, что это потрясение выдержали целевые базы данных небольшого размера, включая SQLite и, возможно, Firebase от Google. Очевидно, что использование единой платформы баз данных не всегда является эффективным выбором для каждого отдельного сценария применения.
Мультимодельная или единая платформа?
Обстоит ли дело так же и с NoSQL/мультимодельными с базами данных или обычные реляционные СУБД могут стать универсальной платформой для удовлетворения потребностей клиентов? Сложно сказать. Такие платформы, как SQL Server, Oracle и Db2, добавили возможности работы с графами в прошлые годы, но их внедрение, похоже, оказалось скромным. Такие платформы, как MongoDB и Couchbase, по-прежнему доминируют в мире хранилищ документов. Cassandra и DataStax продолжают лидировать в категории семейств столбчатых СУБД, а Neo4j, после многих лет конкурентной борьбы, по-прежнему, похоже, является королем графовых СУБД.
Но феномен универсальной РСУБД — это не просто мираж. Основные реляционные базы данных значительно расширили свою поддержку JSON: в 2024 г. Microsoft представила в предварительном режиме нативный тип данных JSON в Azure SQL Database и Azure SQL Managed Instance. В ноябре компания также объявила, что SQL Server 2025 (сейчас находится в стадии частного предварительного просмотра) также будет поддерживать нативный тип данных JSON.
Oracle Database, MySQL, Postgres и другие уже некоторое время имеют надежные реализации JSON. И даже если полномасштабные реализации графов в традиционных СУБД не имели большого успеха, различные возможности in-memory в основных платформах баз данных прекрасно пережили бурю.
Мультимодельные NoSQL также демонстрируют реальную устойчивость. Cosmos DB от Microsoft поддерживает документные, графовые, столбчатые, нативные NoSQL- и полноценные реляционные возможности Postgres в рамках единой платформы. Аналогичным образом, DataStax в явном виде поддерживает столбчатые, табличные, графовые и векторные возможности, а Couchbase — документный режим и режим «ключ-значение».
Озера данных, федерация данных и открытые форматы таблиц
Последняя область, которую следует рассмотреть, — это виртуализация и федерация данных, а также растущая в отрасли поддержка открытых форматов таблиц.
Потребность в запросах к нескольким источникам данных существует уже давно. Десятилетия назад в клиент-серверных базах данных существовала технология запросов к внешним базам данных с помощью таких решений, как Oracle Database Links, Sybase Remote Servers и связанные серверы Microsoft SQL Server. Аналогичным образом, более 30 лет назад важнейшей функцией Microsoft Access была функция удаленной таблицы ядра базы данных Jet, которая могла подключаться к данным в CSV-файлах, электронных таблицах и других базах данных.
С появлением Hadoop и возможности размещения данных на его уровне хранения (позже это стало известно как озера данных) наведение мостов между обычными базами данных и большими данными тоже стало приоритетной задачей. Начиная с технологии под названием SQL-H в давно исчезнувшей Aster Database, приобретенной Teradata в 2011 г., появилась концепция «внешней» таблицы. Изменив синтаксис CRE ATE TABLE, можно было создать логическое представление удаленной таблицы, не копируя ее физически, но при этом механизм запросов мог рассматривать ее как часть локальной базы данных.
Обработка удаленных данных как локальных также называется виртуализацией данных. Объединение удаленной и локальной таблиц (или нескольких удаленных таблиц в разных базах данных) в одном SQL SELECT называется выполнением федеративного (объединенного) запроса. В той или иной степени виртуализация и федерация данных были элегантны в теории, но часто не имели достаточной производительности.
Для решения этой проблемы появились открытые форматы таблиц, и в этом году они стали очень важны. Главными претендентами на победу являются Delta Lake и Apache Iceberg, а Apache Hudi занимает несколько второстепенное место. С практической точки зрения все три OTF основаны на Apache Parquet. В отличие от CSV, других текстовых файловых форматов или даже самого Parquet, данные, хранящиеся в открытых табличных форматах, можно запрашивать, обновлять и управлять ими высокопроизводительным и согласованным образом.
Фактически, для своей платформы Fabric компания Microsoft переработала как свой оригинальный механизм хранилища данных, так и механизм Power BI, чтобы использовать Delta Lake в качестве нативного формата. Snowflake сделала то же самое с Iceberg, и другие производители последовали ее примеру. Между тем, до сих пор существует множество платформ баз данных, которые подключаются к данным, хранящимся в OTF, как к внешним таблицам, а не как к действительно нативным.
Можно ожидать, что в 2025 г. поддержка OTF будет становиться все более мощной, и уже готовиться разрабатывать стратегию работы с данными на ее основе. С поддержкой этих форматов велика вероятность того, что многие, если не большинство, движков баз данных смогут совместно использовать одни и те же физические данные, хранящиеся в этих форматах, запрашивать их на нативных скоростях и работать с ними как в режиме чтения, так и в режиме записи. Проприетарные форматы могут постепенно сдавать свои позиции, а платформы в будущем смогут преуспеть за счет присущих им возможностей, а не за счет реализации обратной связи между их доминированием и возникающей гравитацией данных.
Баланс возможностей и навыков
В конечном счете, единая платформа баз данных не может быть универсальной для всех клиентов и пользователей. Многие из существующих платформ пытаются поддерживать все возможные сценарии использования, но в итоге большинство из них с годами обрастают множеством новых функций, которые оказываются скорее придатками, чем основными элементами.
К счастью, новомодные функции в традиционных базах данных проходят дарвинистский процесс, в итоге сводясь к основному набору возможностей, который, скорее всего, не достигнет паритета со специализированными платформами баз данных, но, тем не менее, будет достаточным для большинства потребностей клиентов. По мере того как отсеиваются лишние возможности, важные функции «рабочей лошадки» становятся частью канона разработки баз данных и приложений.
Рынок работает так, как и должен работать: в ответ на конкурентное давление со стороны новых игроков традиционные компании добавляют функции, которые они, скорее всего, не стали бы добавлять по собственной инициативе. Это открывает возможности для новых инновационных игроков, а также позволяет клиентам, которые хотят инвестировать в существующие платформы, сделать именно это.
Интересно, что основы реляционной алгебры, SQL-запросов и т. п. остаются актуальными на протяжении десятилетий, тогда как полезность, совместимость и применимость СУБД продолжают расти. Это означает, что инвестиции в наборы навыков и технологии не только защищены, но и, как хорошие финансовые инвестиции, растут в цене и приносят дивиденды.
Некоторые заказчики захотят получить преимущество первыми, и поэтому совершенно новые, инновационные платформы придутся им по вкусу. Но многие заказчики не захотят перестраивать платформу или отказываться от инвестиций в свои навыки и предпочтут, чтобы поставщики расширяли существующую дорогу, а не прокладывали к ней обходные пути. Эти организации должны требовать этого и делать ставку на тех поставщиков, которые используют такие подходы. И в 2025 г. им следует ожидать, что такие поставщики будут приветствовать и удовлетворять их.
