СУБД: вчера, сегодня и завтра

Гладко на бумаге, но забыли про овраги

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

Главная тенденция — это развитие открытого ПО в целом и открытых СУБД в частности. Сейчас поднялась волна «закрытий» — сменой ранее свободных лицензий на коммерческие. CockroachDB, Redis, Greenplum — это только некоторые крупные игроки, недавно заявившие о смене лицензий. Резко сократилось и количество новых вендоров СУБД, выходящих на рынок. Все это явно свидетельствует о повышении конкуренции, в первую очередь со стороны облачных сервисов, таких как DynamoDB, DataBricks, Snowflake.

Что это значит для России? До сегодняшнего момента российские компании, в том числе крупные корпорации, активно использовали бесплатные открытые версии ПО, благо качество community-версий почти не уступало коммерческим вариантам. Экономия на инфраструктурном ПО — один из ключевых факторов, позволивших стране достичь передовых позиций в таких секторах, как банки и финансы, телекоммуникации, цифровые сервисы. ИТ-директора крупнейших российских компаний воспринимали открытое ПО как не очень качественный, но зато бесплатный аналог корпоративного ПО от Oracle и SAP. В новой реальности российским корпорациям снова придется сменить парадигму, опираясь на немногие открытые международные проекты, а также на отечественных или китайских вендоров. Затраты на инфраструктурное ПО при этом неизбежно вырастут.

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

Интересна тенденция развития DBaaS и PaaS за рубежом. Изначально DBaaS-платформы, такие как Amazone Aurora либо Google Cloud SQL, основывались на заимствованных у сообщества Open Source довольно примитивных кластерных возможностях. При этом экономическая ценность (value proposition) этих сервисов заключалась лишь в автоматизации развертывания и обработке отказов, то есть сокращении издержек на администрирование. Примерно такая сегодня ситуация с большинством облачных СУБД и в России. Однако за два десятилетия западные облачные СУБД прошли путь к горизонтальному масштабированию до десятков и сотен петабайт, поддержке распределенных транзакций, аналитических запросов, возможностей ИИ — сегодня это стандартный набор для всех новых проектов в западных компаниях. С другой стороны, привязка к поставщику (vendor lock-in) при использовании DBaaS оказывается даже выше, чем при использовании проприетарного ПО. Таким образом, западный рынок рискует надолго застрять в этой модели потребления.

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

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

— Константин Осипов (kostja@picodata.io) — сооснователь и технический директор компании Picodata, эксперт по базам данных с 25-летним стажем. Имеет опыт преподавания на ВМиК МГУ и в ШАД «Яндекса», автор публикаций и докладов на российских и международных конференциях, член программного комитета Highload и российского сообщества разработчиков СУБД и распределенных систем Database internals.

На пути к конвергентным СУБД

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

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

Во-вторых, есть большие сомнения в смерти Hadoop и Big Data. Реляционные СУБД не обеспечивают необходимую для работы с большими данными производительность при работе с огромными массивами данных. РСУБД просто не успевает распределять поступающие данные по таблицам, а тем более вести массовую параллельную обработку — Data Lake (обычно подразумевают как системы над Hadoop) вместе с Lakehouse не заменят Map-Reduce. В случае с поколоночными СУБД примечателен подход Oracle, совмещающий преимущества реляционной и поколоночной модели хранения — на диске работает реляционная модель, а в памяти — обе, реализуя преимущества каждой. Кроме этого, почему в статье перемещение обработки ближе к месту хранения данных подается как преимущество облака? Это давно уже реализовано в машинах баз данных у Teradata, в Oracle Exadata, в Greenplum и будет дальше использоваться в OLAP. Облачная модель, конечно, вещь хорошая, но, как мы сегодня наблюдаем в России, нормотворчество ее убивает.

В-третьих, почему-то в статье распределенные СУБД отнесены к NewSQL и авторы уделили им мало внимания, хотя, несмотря на лавинообразный рост объемов данных и нагрузок, на рынке очень мало универсальных СУБД, умеющих работать с петабайтными базами. В этой связи (особенно в России) большие перспективы у сегментирования (шардирования) и распределенной параллельной обработки. Это справедливо и для автономных баз данных, о которых авторы говорят вскользь, хотя очень важен перенос именно на сторону вендора всех работ и настроек под конкретную ИТ-инфраструктуру. Это достаточно трудоемкая задача и для РСУБД, не говоря уже и про более сложные СУБД. Автономные базы позволяют резко ускорить и упростить получение ресурсов СУБД, а пользователь должен заниматься своим делом (разработка, тестирование, изучение, внедрение приложений), а не установкой и администрированием СУБД.

У авторов есть странная фраза «…многозадачные СУБД с разделяемым диском — не принесли успеха», а как же RAC (Real Application Cluster)? Он очень востребован, и часто СУБД Oracle, несмотря на цену, покупают именно из-за него.

Сегодня очень актуальна тема аппаратных ускорителей — сейчас для многих приложений важна производительность, однако все попытки встроить в процессор команды SQL провалилась и пока перешли к использованию SIMD-команд стандартного процессора и GPU. Кроме этого применяется специальное сетевое оборудование, развиваются машины баз данных и ПАК. Проблема в том, что это дорого, сложно и по силам только крупным производителям и ПО, и оборудования (Oracle, IBM и т. п.), а также мощным облачным провайдерам (Google, Yandex, Amazon и «Скала-р»).

Определенные сомнения вызывают и выводы авторов манифеста: «остерегайтесь СУБД крупных компаний, не связанных с базами данных». Не надо остерегаться СУБД от таких крупных компаний, как Google, MS и Amazon, — все они делают хорошие СУБД. Скорее всего, стоит предостеречь от множества небольших отечественных производителей ОС, финансовых приложений и пр., решивших, что сделать СУБД — это просто, достаточно выпустить собственные форки, которые часто почти не отличаются от ванильного продукта, но выбор заказчику усложняют. Для выпуска и развития хорошей СУБД нужен опыт, знания, выстроенная система разработки/сборки/тестирования/документирования/поддержки, а главное — ресурсы и квалифицированные специалисты, умеющие делать системное ПО, понимающие устройство СУБД, оптимизаторов, системы мониторинга и управления и т. д.

Сегодня многие компании стали заявлять о выпуске на рынок своих машин баз данных — конкурентов Oracle Exadata, при этом они даже не понимают, что Exadata — это не просто набор стандартных компьютеров в одном корпусе, на которые установлена СУБД, настроенная на ресурсы данного оборудования, система резервного копирования и система мониторинга (у Oracle это называлось сертифицированной конфигурацией). Система Exadata кроме подобранного и настроенного оборудования, оптимизированных сетевых протоколов, встроенных компонентов хранения, энергонезависимой памяти и пр. имела специальную архитектуру (умные ячейки хранения) и RAC на основных компьютерах, а главное — специальное ПО ячеек. Это ПО обеспечивало «smart scan» — передача частей запроса на ячейки, к данным и их параллельная обработка; smart flash cache (умное кэширование), поколоночное сжатие, специальные виды индексирования, дополнительные сетевые каналы для каждой ячейки, механизмы для работы с петабайтными базами и пр. Ничего подобного в заявленных российских продуктах нет. В стране есть хорошие программно-аппаратные комплексы, упрощающие развертывание СУБД и инфраструктуры, но это не машины баз данных, что вводит в заблуждение заказчиков.

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

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

— Марк Ривкин (m.rivkin@postgrespro.ru) — руководитель отдела предпродажной подготовки, компания Postgres Pro. Эксперт в области СУБД — более 40 лет опыта работы в сфере продвижения СУБД разных производителей: Oracle, IBM, Postgres Pro. Автор ряда публикаций и учебных курсов по теории и практике баз данных.

А был ли мальчик?

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

Авторами утверждается, что за последние две декады были попытки заместить реляционную модель Э. Кодда и язык SQL, созданный Д. Чемберлином и Р. Бойсом. Однако так ли это? На мой взгляд за более чем полувековую историю реляционных баз данных, изменивших весь ландшафт хранения и обработки данных, происходили попытки кардинальной смены модели взаимодействия с базой данных. Я бы отнес сюда развитие объектно-реляционного подхода, модели данных XML и языка Xquery, а также, частично, документных баз данных. Кроме этого постоянно шла эволюция баз данных и систем хранения как ответ на возникающие потребности рынка — это прежде всего рост объема данных, часто взрывообразный. Отсюда появление eventually consistent (согласованность в конечном счете) распределенных хранилищ ключ-значение (KV) и хранение аналитических данных в объектном хранилище типа Amazon S3. Новые технологии появлялись реже, например, в ответ на рост популярности больших языковых моделей (LLM) производители баз данных стали пытаться удовлетворить новые потребности.

Попытка кардинально поменять модель данных

На мой взгляд, таких попыток за последние 20 лет почти не было — лишь в начале нулевых была последняя попытка изменить модель общения с базой данных общего (именно общего) назначения. Это было связано с акцентом на слабоструктурированные данные — дескать, «хорошо, когда ваши данные имеют структуру, тогда для них подходит реляционная алгебра и язык SQL», а если четкой структуры нет или она меняется, то приходится изобретать новые подходы. Исследования в области XML и языка запросов XQuery закончились построением нескольких промышленных систем и встраиванием средств хранения и работы с XML-данными во все крупные СУБД. Отголоски этой неудавшейся революции мы наблюдаем сейчас в виде документных баз данных. С точки зрения промышленного применения они оказались успешнее. Но, похоже, закончат так же — средства работы с json встроены сегодня почти в любую СУБД.

Эволюция СУБД как ответ на потребности рынка

Почти все «интересное», про что с удовольствием читаешь в статье, — это ответ индустрии на потребности рынка. Начнем с KV-хранилищ. Именно они позволили Интернет-компаниям справиться с растущей нагрузкой. В том числе с нагрузкой на эксплуатацию — проще обслуживать кластер из 100 узлов, чем 100 инстансов базы данных. Тот же подход Map Reduce, хоть и «умер» по мировым меркам, позволил Интернет-компаниям совершить чудо в области обработки данных. Особенно хорош раздел статьи про системные архитектуры. Колоночное хранение, облачные базы данных, озера данных и NewSQL (я бы использовал термин DistributedSQL-базы данных) — это то, что сегодня актуально, без чего я не представляю себе индустрию СУБД.

Я полностью согласен с выводами Стоунбрейкера и Павло, но не согласен с посылом авторов, что были (серьезные игроки) желающие поменять устои. Я бы, скорее, акцентировался на том, что индустрия хранения данных сделала качественный технологический рывок за последние 20 лет, но осталась верна реляционной модели. И этот рывок — распределенные базы данных и системы хранения. Именно технологии распределенных вычислений смогли помочь индустрии:

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

Именно работа над распределенными базами данных подарили нам такие достижения, как:

• инженеры на собеседованиях не только демонстрируют знания SQL-синтаксиса, но и (базовое) понимание алгоритмов распределенного консенсуса таких, как Paxos или Raft;
• хранилище S3 демонстрирует бесконечное масштабирование и приемлемые цены хранения петабайтов данных;
• возможность обрабатывать петабайты аналитических данных;
• возможность наращивать OLTP-нагрузку до небывалых ранее показателей в миллионы запросов в секунду.

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

— Андрей Фомичев (fomichev@ydb.tech) — основатель и руководитель YDB. Эксперт в области баз данных с более чем двадцатилетним стажем. Окончил ВМиК МГУ, к.ф.-м.н. В «Яндексе» отвечает за YDB, платформу Observability и направление Serverless в Yandex Cloud.

Весь ли OLAP будет SQL?

«Человеку с молотком все вокруг кажется гвоздями» — эта фраза, похоже, применима и к авторам манифеста. Вертикальные, векторные, документоориентированные, графовые и прочие СУБД, согласно выводам авторов, — первопроходцы новых переулков в области хранения данных, пока туда не ступит тяжелая нога монстров в лице Microsoft и Oracle, которые непременно если не поглотят новичков-стартапов, то воспроизведут новые идеи в своих экосистемах. Исключения типа Snowflake (основанного опытными архитекторами из Oracle) только подтверждают правило.

По мнению гуру СУБД, весь OLAP в конце концов станет частью SQL, однако более-менее экспертного взгляда на Microsoft SQL Server и Microsoft OLAP достаточно, чтобы понять — в задачах аналитической обработки языка SQL и возможностей РСУБД недостаточно. Более того, как следует из книги 'Unified Star Schema' Билла Инмона и Франческо Пуппини — гуру в области бизнес-аналитики, использование реляционной модели для большинства BI-расчетов приводит к неразрешимым проблемам: «ловушке пропасти», «ловушке веера» и взрыву данных, что делает невозможным истинный Self Service BI.

Современные BI-инструменты уходят от SQL-запросов — при создании в них моделей данных пользователю уже не нужно указывать тип объединения таблиц (join), а ведь именно join приводит к ошибкам. Лидеры рынка BI заменяют join на ассоциативные вычисления и делают их в момент расчета, а не предварительно, как в SQL. Причина — в иной природе работы с данными. Самое популярное средство анализа — это сводная таблица, которую невозможно описать, используя стандартный синтаксис SQL. Более того, получив сводную таблицу, пользователь выполняет в ней такие не характерные для баз данных специфические операции, как раскрытие узлов, создание иерархий, контекстно-зависимые расчеты. Для этого придуманы другие языки (DAX, например), ориентированные именно на многомерность данных, — так гораздо удобнее анализировать большие объемы данных.

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

— Роман Раевский (rar@rapeed.ai) — автор технологии распределенных аналитических онлайн-вычислений rapeed. Эксперт в области бизнес-аналитики — четверть века опыта разработки аналитических технологий и руководства крупнейшими проектами внедрения BI.

Надежда на то, что железо все решит, — иллюзия

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

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

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

— Олег Бартунов (o.bartunov@postgrespro.ru) — сооснователь и генеральный директор компании российского разработчика СУБД Postgres Professional. Окончил физический факультет МГУ им. М. В. Ломоносова, использовал PostgreSQL для решения задач астрономии, а с 1996 года участвовал в разработке этой СУБД. Совместно с Федором Сигаевым разработал для PostgreSQL систему полнотекстового поиска, средства поддержки слабоструктурированных данных, индексные методы доступа, в том числе к пространственным данным, а также разнообразные расширения для СУБД. Имеет статус Major Contributor PostgreSQL.

Искусственный интеллект без искусственной совести — экзистенциальная угроза

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

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

— Иван Панченко (info@postgrespro.ru) — сооснователь и заместитель генерального директора Postgres Professional, к. физ.-мат. наук, астрофизик, программист. Занимался разработкой сложных высокопроизводительных систем для бизнеса, информационных систем и порталов, ключевых компонентов СУБД PostgreSQL в интересах ряда крупных российских компаний. Руководитель комитета по интеграции российского программного обеспечения ассоциации разработчиков «Отечественный софт».

Новации приходят и уходят, а реляционная модель остается

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

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

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

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

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

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

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

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

— Дмитрий Еманов (dmitry.yemanov@red-soft.ru) — ведущий архитектор СУБД Ред База Данных, team leader Firebird. Занимается разработкой программного обеспечения с 1997 года, с 2000 года — контрибьютор FirebirdSQL, а с 2004 года — ведущий разработчик. Имеет более чем 30-летний опыт разработки СУБД, регулярно выступает на российских и международных конференциях по базам данных.

Реляционная модель — нестареющая классика

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

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

• во-первых, возможность реляционного доступа к данным будет весомым преимуществом любой системы. Кстати, в качестве примера следует упомянуть возможности LINQ в языке C#;
• во-вторых, действительно будут интересны различные средства, помогающие организовать реляционный доступ к уже существующим массивам данных (Apache Calcite, Orca, Data Fusion и т. д.), хотя пока преждевременно говорить о стандартизации подобных инструментов;
• в-третьих, крайне важным будет простота использования систем (минимальные зависимости от стороннего ПО, легкость интеграции и т. д.) на широком спектре распространенного оборудования (при этом максимально используя его возможности). Далеко не все существующие на рынке решения (в т. ч. и SQLite) могут похвастаться таким свойством, поскольку их архитектура уходит корнями в 90-е годы прошлого века и не всегда учитывает современные реалии: быстрая сеть, быстрые диски, многоядерные процессоры, объемы оперативной памяти и т. д.

Еще очень долго будут востребованы классические реляционные и легкие в использовании СУБД (HyperDB, UbmraDB/CedarDB, СОКОЛ), максимально использующие доступное оборудование. Классическая реляционная СУБД в информационной системе — это как маленькое черное платье, в котором невозможно выглядеть чересчур шикарно или слишком скромно, оно всегда остается модным и актуальным.

— Константин Селезнев (konstantin_seleznyov@relex.ru) — главный специалист компании РЕЛЭКС, эксперт в области систем обработки данных с 25-летним стажем, автор множества публикаций по теории и практике СУБД (Воронеж).