То, как мы храним и обслуживаем данные, является критическим фактором того, что мы можем делать с ними, а сегодня мы хотим делать очень много. Необходимость в больших данных — мать всех изобретений, и за последние 20 лет она дала толчок огромному количеству творений в области баз данных, от MapReduce и баз данных массивов (array databases) до NoSQL и векторных БД. Все это кажется таким многообещающим... и тут свое слово решил сказать профессор МТИ Майкл Стоунбрейкер, сообщает портал Datanami.

На протяжении полувека Стоунбрейкер создавал базы данных в бешеном темпе. Лауреат премии Тьюринга сперва смог зарекомендовать себя, создав Ingres и Postgres. Однако, видимо, не удовлетворившись созданием самой популярной в мире базы данных (PostgreSQL), он также создал Vertica, Tamr, VoltDB и др. Его последнее начинание: инверсия всей вычислительной парадигмы с помощью операционной системы, ориентированной на базу данных (DBOS).

Стоунбрейкер также известен своими откровенными оценками баз данных и индустрии обработки данных. Известно, что он не раз лопал пузыри и зарезал парочку священных коров. Когда Hadoop был на пике популярности в 2014 г., Стоунбрейкер с явным удовольствием отметил, что Google (источник технологии) уже перешла от MapReduce к чему-то другому — BigTable.

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

Еще в 2005 г. Стоунбрейкер и два его студента, Питер Бейлис и Джо Хеллерштейн, проанализировали предыдущие 40 лет проектирования баз данных и поделились своими выводами в работе под названием «Readings in Database Systems». В ней они пришли к выводу, что реляционная модель и SQL стали лучшим выбором для СУБД, обойдя другие идеи, включая иерархические файловые системы, объектно-ориентированные базы данных и базы данных XML, среди прочих.

В своей новой статье «What Goes Around Comes Around... And Around...», опубликованной в июньском выпуске SIGMOD Record, легендарный компьютерщик из Массачусетского технологического института и его соавтор, Эндрю Павло из Университета Карнеги-Меллон, анализируют последние 20 лет разработки баз данных. Как они отмечают, «со времени исследования 2005 г. в мире баз данных произошло много событий».

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

20 лет развития баз данных

Вот что авторы пишут о новых изобретениях в области баз данных за последние 20 лет:

  • MapReduce. Системы MapReduce, наиболее заметной и (на какое-то время) успешной реализацией которых был Hadoop, мертвы: «Они умерли много лет назад и в настоящее время являются в лучшем случае устаревшей технологией».
  • Хранилища «ключ-значение». Эти системы (Redis, RocksDB) либо «переросли в системы RM [реляционная модель], либо используются только для решения специфических задач».
  • Хранилища документов. Базы данных NoSQL, которые хранят данные в виде документов JSON, такие как MongoDB и Couchbase, выиграли от энтузиазма разработчиков по поводу денормализованных структур данных, низкоуровневых API и горизонтальной масштабируемости за счет ACID-транзакций. Однако хранилища документов «находятся на пути столкновения с РСУБД», пишут авторы, поскольку те перешли на SQL, а реляционные базы данных добавили горизонтальную масштабируемость и поддержку JSON.
  • Колоночные базы данных. Это семейство баз данных NoSQL (BigTable, Cassandra, HBase) похоже на хранилища документов, но с одним уровнем вложенности вместо произвольного количества. Однако, по мнению авторов, семейство колоночных хранилищ уже устарело. «Если бы не Google, эта статья не была бы посвящена данной категории», — пишут они.
  • Текстовые поисковые системы. Поисковые системы существуют уже 70 лет, и современные поисковые системы (такие как Elasticsearch и Solr) продолжают быть популярными. Они, скорее всего, будут существовать отдельно от реляционных баз данных, потому что выполнение поисковых операций на SQL «часто бывает громоздким и отличается в разных СУБД», пишут авторы.
  • Базы данных массивов. Базы данных, такие как Rasdaman, kdb+ и SciDB (творение Стоунбрейкера), хранящие данные в виде двумерных матриц или тензоров (три и более измерений), популярны в научном сообществе и, скорее всего, останутся таковыми, «поскольку СУБД не могут эффективно хранить и анализировать массивы, несмотря на новые усовершенствования SQL/MDA», пишут авторы.
  • Векторные базы данных. Специализированные векторные базы данных, такие как Pineone, Milvus и Weaviate (среди прочих), — это «по сути, документо-ориентированные СУБД со специализированными индексами ANN [приблизительных ближайших соседей]», пишут авторы. Одним из их преимуществ является то, что они лучше интегрируются с инструментами ИИ, такими как LangChain, чем реляционные базы данных. Однако долгосрочная перспектива векторных БД не очень хороша, поскольку РСУБД, скорее всего, смогут перенять все их возможности, «сделав такие специализированные базы данных ненужными».
  • Графовые базы данных. Базы данных графов свойств (Neo4j, TigerGraph) заняли комфортную нишу благодаря своей эффективности в определенных типах рабочих нагрузок OLTP и OLAP на связанных данных, где выполнение джойнов в реляционной базе данных привело бы к неэффективному использованию вычислительных ресурсов. «Но их потенциальный успех на рынке зависит от того, достаточно ли существует сценариев „длинной цепочки“, в которых стоит отказаться от РСУБД», — пишут авторы.

Тенденции в архитектуре баз данных

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

  • Колоночные хранилища. Реляционные базы данных, хранящие данные в столбцах (в отличие от строковых), такие как Google Cloud BigQuery, AWS Redshift и Snowflake, стали доминировать на рынке хранилищ данных/OLAP, «благодаря своей превосходной производительности».
  • Облачные базы данных. Самая большая революция в проектировании баз данных за последние 20 лет произошла в облаке, пишут авторы. Благодаря значительному росту пропускной способности сетей по сравнению с пропускной способностью дисков, размещение данных в объектных хранилищах через сетевые хранилища (NAS) стало очень привлекательным. Это, в свою очередь, подтолкнуло к разделению вычислений и хранения данных, а также к появлению бессерверных вычислений. Переход к облачным вычислениям создал для предприятий «единственную в жизни возможность рефакторинга кодовых баз и устранения неудачных исторических технологических решений, — пишут авторы. — За исключением встроенных СУБД, любой продукт, не начинающийся с облачного предложения, скорее всего, потерпит неудачу».
  • Озера данных/озера-хранилища (lakehouses). Опираясь на рост облачных объектных хранилищ, эти системы «являются преемниками движения Big Data начала 2010-х», пишут авторы. Такие табличные форматы, как Apache Iceberg, Apache Hudi и Databricks Delta Lake, сгладили то, что «кажется ужасной идеей», то есть позволили любому приложению записывать произвольные данные в централизованное хранилище, пишут авторы. Еще одним преимуществом архитектуры озера-хранилища является возможность поддержки рабочих нагрузок, не связанных с SQL, например, работы специалистов в области науки о данных в блокноте с помощью Pandas DataFrame API. Это «будет архетипом OLAP-СУБД на ближайшие десять лет», — считают они.
  • Системы NewSQL. Появление новых реляционных (или SQL-) баз данных, которые масштабируются горизонтально, как базы данных NoSQL, не отказываясь от ACID-гарантий, могло показаться хорошей идеей. Но этот класс баз данных, таких как SingleStore, NuoDB (сейчас принадлежит Dassault Systems) и VoltDB (творение Стоунбрейкера), так и не прижился, в основном потому, что существующие базы данных были «достаточно хороши» и не было оснований рисковать с переходом на новую базу данных.
  • Аппаратные ускорители. За последние 20 лет появилось множество аппаратных ускорителей для OLAP-нагрузок, использующих как FPGA (Netezza, Swarm64), так и GPU (Kinetica, Sqream, Brylyt и HeavyDB [ранее OmniSci]). В наши дни немногие компании помимо облачных гигантов могут оправдать затраты на создание собственного оборудования для баз данных, пишут авторы. Но надежда на более быстрые данные никогда не умирает. «Несмотря на низкие шансы, мы прогнозируем, что в ближайшие два десятилетия в этой области будет предпринято множество попыток», — пишут они.
  • Базы данных на основе блокчейна. Блокчейн-базы данных, которые когда-то рекламировались как будущее хранения данных без доверия, сегодня являются «угасающим увлечением в области технологий баз данных», пишут авторы. Дело не в том, что эта технология не работает, просто у нее нет применения за пределами «темной паутины». «Законопослушные предприятия не желают платить за использование СУБД на основе блокчейна такую цену (примерно на пять порядков больше), — пишут они. — Неэффективная технология ищет себе применение. История показывает, что это неправильный подход к разработке систем».

Взгляд в будущее: все останется реляционным

В конце статьи у читателя остается неизгладимое впечатление, что «то, что всегда возвращается на круги своя», — это реляционная модель и SQL. Сочетание этих двух сущностей будет трудно победить, но попытки все равно будут, пишут Стоунбрейкер и Павло.

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

Так что же ждет разработчиков баз данных в будущем? Авторы призывают сообщество разработчиков баз данных «содействовать развитию многократно используемых Open Source-компонентов и сервисов. В настоящее время предпринимаются определенные усилия для достижения этой цели, в том числе для файловых форматов [Iceberg, Hudi, Delta], оптимизации запросов (например, Calcite, Orca) и движков выполнения (например, DataFusion, Velox). Мы считаем, что сообщество баз данных должно стремиться к POSIX-подобному стандарту внутреннего устройства СУБД, для ускорения интероперабельности».

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