What Goes Around Comes Around... And Around...
Разбор статьи Stonebraker и Pavlo о развитии баз данных: data models, архитектуры DBMS и практические уроки последних 20 лет.
Практика чтения для этого источника ещё не опубликована
Ниже доступен готовый редакционный brief из прежнего каталога. Он даёт контекст, но не засчитывается как lab.
Открыть оригиналГотовый редакционный разбор
Он сохранён из прежней версии каталога и расположен после самостоятельной практики, чтобы не подменять чтение оригинала готовым пересказом.
Основной источник
What Goes Around Comes Around... And Around...
SIGMOD Record, 2024: ретроспектива эволюции DBMS за 20 лет.
Основной источник
What Goes Around Comes Around... And Around...
SIGMOD Record, 2024: ретроспектива эволюции DBMS за 20 лет.
Статья 2024 года от Michael Stonebraker и Andrew Pavlo продолжает обзор 2005 года и проверяет, какие идеи DBMS действительно выдержали время: от data models и SQL до архитектур cloud/lakehouse/NewSQL.
Первая страница whitepaper (клик по изображению откроет PDF).
Предыстория
What Goes Around Comes Around (2005)
Stonebraker и Hellerstein о 35-летней истории DBMS и прогнозах развития.
Предыстория
What Goes Around Comes Around (2005)
Stonebraker и Hellerstein о 35-летней истории DBMS и прогнозах развития.
Контекст и авторы
Stonebraker известен как создатель Postgres, а Pavlo исследует и преподаёт архитектуру БД; часть его лекций доступна на YouTube.
В 2005 году авторы предупреждали, что объектные и XML СУБД вряд ли вытеснят реляционную модель. Спустя почти 20 лет они снова поднимают тот же вопрос, но уже в мире cloud, vector search и новых распределённых SQL-систем.
Как устроен разбор (части 1/3, 2/3 и 3/3)
Part I
Data models и query languages: где NoSQL остался нишей, а где приблизился к возможностям RDBMS.
Part II
Архитектуры за 20 лет: columnar, cloud DB, data lake/lakehouse и NewSQL.
Part III
Хвост архитектур (accelerators, blockchain DB) и практические предостережения авторов.
Модели данных и языки запросов
Первая часть статьи проходит по восьми классам систем и показывает, что многим «альтернативам SQL» всё равно пришлось перенять зрелые элементы реляционного мира.
MapReduce-системы
BatchMapReduce создавался в Google для массовой batch-обработки (например, индексации web-crawl) и не диктовал жёсткую модель данных.
- Запросная модель строится вокруг пользовательских map/reduce-функций, а не декларативного языка вроде SQL.
- Открытый Hadoop стал массовым стандартом, но заметно уступил современным платформам по производительности и интерактивности.
Примеры: MapReduce paper · Hadoop · Apache Spark
Key-Value хранилища
Cache-firstСамая простая data model: пары «ключ-значение», которые отлично подходят для кэшей, сессий и простых high-throughput сценариев.
- Классические ограничения: нет join и полноценной реляционной алгебры, а индексные возможности ограничены.
- Многие системы со временем добавили JSON и вторичные индексы, сближаясь с более богатыми моделями.
Примеры: Memcached · Redis · DynamoDB · Aerospike · LevelDB · RocksDB
Документные базы данных
JSONДокументная модель (JSON-подобные объекты) была популярна как простой путь интеграции с веб-приложениями и практикой schema-on-read.
- К 2020-м большинство document DB добавили SQL-подобные интерфейсы, ACID-транзакции и элементы schema-on-write.
- Практическая дистанция между document и relational подходами стала заметно меньше.
Примеры: MongoDB
Column-family (wide column)
Scale-outWide-column модель унаследовала идеи Bigtable: масштабируемость и гибкость для распределённых нагрузок при более ограниченной структуре данных.
- Ранние версии систем вроде Cassandra не имели полноценной поддержки вторичных индексов и транзакций.
- С развитием экосистемы появились LWT и дополнительные индексные механизмы, но с заметными компромиссами.
Примеры: Bigtable · Apache Cassandra · Cassandra trade-offs
Поисковые движки
SearchСпециализированы под полнотекстовый поиск и inverted-index workloads: быстрый search, агрегации и релевантность.
- Сильны в поиске, но обычно ограничены в транзакционных гарантиях относительно классических OLTP DBMS.
- Реляционные СУБД тоже умеют full-text, но API часто менее удобен, чем у dedicated search-движков.
Примеры: Elasticsearch · Apache Solr
Базы данных для массивов
ScientificОриентированы на многомерные массивы в научных доменах: геопространственные, геномные и другие вычислительно-интенсивные задачи.
- Ниша относительно узкая, но для специализированных вычислений такие системы остаются важными.
- Модель данных и API обычно заточены под научные сценарии, а не массовый enterprise OLTP.
Векторные базы данных
EmbeddingsФокус на хранении эмбеддингов и поиске ближайших соседей в высокоразмерных пространствах для AI/ML workloads.
- Сильны в ANN-сценариях, где классические индексы работают плохо или не работают вовсе.
- Реляционные движки активно добавляют vector extensions и индексы, снижая потребность в отдельном сервисе.
Графовые базы данных
GraphГрафовая модель (узлы и рёбра) удобна для сценариев с богатыми связями: fraud, рекомендаций, knowledge graph и маршрутизации.
- Для OLTP-графов популярен Neo4j, для аналитики графов часто используют отдельные движки.
- С выходом SQL:2023 (SQL/PGQ) часть графовых кейсов переезжает в экосистему реляционных СУБД.
Примеры: Neo4j · TigerGraph · SQL:2023
Общие выводы по data models
Большинство нереляционных систем либо заняли узкие ниши, либо сблизились с реляционным миром по возможностям.
SQL остаётся центральным языком запросов за счёт выразительности, переносимости и зрелой экосистемы инструментов.
Реляционные СУБД продолжают расширяться: JSON, graph/query extensions и vector index становятся частью «базы по умолчанию».
Архитектуры DBMS за последние 20 лет
Части 2/3 и 3/3 связывают архитектурные решения с изменениями в software и hardware: быстрее сети, новые storage-модели и рост требований к эластичности.
Колоночные системы
OLAPЗа последние два десятилетия колоночное хранение стало стандартом аналитических DBMS благодаря эффективному I/O и сжатию.
- OLAP-запросы обычно читают лишь часть колонок, поэтому columnar layout резко снижает объём чтения.
- Однородность значений внутри колонок помогает компрессии, а векторизованная обработка ускоряет выполнение.
Примеры: Vertica · Amazon Redshift · BigQuery · ClickHouse · DuckDB
Облачные базы данных
CloudРост пропускной способности сетей относительно дисков сделал viable архитектуру с разделением compute/storage и внешним NAS на базе объектных хранилищ.
- Compute и storage масштабируются независимо: можно держать гибкую эластичность даже под отдельные запросы.
- Если вычислительные ноды простаивают, их можно перераспределять на другие задачи без миграции данных.
- Модель pushing query to the data часто выгоднее классического pulling data to the query.
Примеры: Snowflake · Google Spanner paper · Amazon Aurora paper · Aurora sharding talk
Data Lakes и Lakehouse
LakehouseCloud-платформы ускорили переход от монолитных аналитических хранилищ к data lake + lakehouse-подходу с хранением «сырых» данных в object storage.
- На практике это сдвиг от ETL к ELT: сначала загрузка, затем трансформации поверх уже загруженных данных.
- Lakehouse-движки выполняют вычисления поверх открытых форматов и частично замещают классические DWH-схемы.
Примеры: Parquet · ORC · Apache Arrow · Databricks · Dremio · PrestoDB · Trino
NewSQL
Distributed SQLКласс систем 2010-х, пытавшийся совместить ACID-транзакции традиционных RDBMS с горизонтальной масштабируемостью NoSQL.
- Ранний рынок разделился на in-memory и disk-oriented подходы; in-memory-ставки оказались менее устойчивыми.
- Закрепились распределённые транзакционные SQL-системы, которые сочетают консистентность и масштаб.
Примеры: Google Spanner · TiDB · CockroachDB · YDB
Аппаратные ускорители
HardwareGPU/FPGA и другие accelerators дают прирост в отдельных workloads, но требуют дорогостоящей интеграции железа и software stack.
- Подход чаще выгоден крупным cloud-вендорам, где есть масштаб и ресурсы на кастомную инфраструктуру.
- Для большинства команд эффект редко оказывается кратным относительно сложности внедрения.
Базы данных на блокчейне
NicheИдея неизменяемости и прозрачности транзакций привлекательна, но в универсальных enterprise-кейсах подход остаётся нишевым.
- Главные ограничения: производительность, операционная сложность и непростая интеграция с классическими приложениями.
- В массовом DBMS-рынке блокчейн-архитектуры пока не стали стандартом.
Выводы по архитектурам
Колоночные движки фактически стали стандартом OLAP.
Облачные DBMS доминируют благодаря управляемости и эластичности.
NewSQL закрепился как мост между ACID-моделью и масштабированием.
Специализированные архитектуры чаще остаются нишей или интегрируются в большие платформы.
Прощальные комментарии авторов
Не переоценивать маркетинговый шум: история Oracle (1980-е), MySQL (2000-е) и MongoDB (2010-е) показывает, что хайп не равен качеству.
Осторожно относиться к DBMS от big tech вне core-рынка баз данных: иногда рождаются отличные продукты, но нередко появляются сырые решения.
Out-of-box опыт критичен: если старт с продуктом сложный, пользователи быстро уходят к notebooks и обходным путям.
Даже при активном использовании ORM разработчикам по-прежнему нужно уметь писать SQL напрямую.
AI/ML повлияют на DBMS (особенно в OLAP и автотюнинге), но не заменят системную инженерию и архитектурную дисциплину.
Отдельный штрих из финала статьи: авторы уже иронично обещают вернуться с новым продолжением в 2044 году.
Что взять в практику
Выбирать движок от требований workload, а не от тренда: OLTP, OLAP, search и vector часто требуют разных компромиссов.
Закладывать эволюцию модели данных заранее: многие «NoSQL-only» продукты со временем всё равно приходят к SQL/ACID-функциям.
Проектировать облачные хранилища вокруг separation of concerns между compute и storage, чтобы не переплачивать за idle-ресурсы.
Оценивать инструменты через DX и операционные затраты: быстрый пилот без поддержки эксплуатации редко масштабируется.
Связанные главы
Оригинальный разбор
Серия постов в tg-канале
Три части разбора статьи: data models, архитектуры и итоговые комментарии.
Оригинальный разбор
Серия постов в tg-канале
Три части разбора статьи: data models, архитектуры и итоговые комментарии.