What Goes Around Comes Around... And Around... Part I (Рубрика #Data)Интересная обзорная
статья 2024 года от
Michael Stonebraker и
Andrew Pavlo про развитие баз данных за последние 20 лет. Оба автора являются корефееями в области баз данных: Michael создал
Postgres и еще кучу других баз, а Andrew - исследователь в области баз данных, профессор и преподаватель, лекции которого
доступны на Youtube.
Сама статья продолжает статью 2005 года "
What Goes Around Comes Around", которую написали Michael Stonebraker и Joseph M. Hellerstein. Они проанализировали историю развития баз данных за 35 лет и предсказали что модные тогда объектные и xml базы данных не смогут обойти по реляционную модель.
С тех пор прошло порядка 20 лет и пришло время сделать новый обзор мира баз данных. Для этого авторы решили посмотреть на это с двух сторон:
- Модели данных и языки запросов
- Архитектура баз данных
Начнем с разбора существующих data models и query languages:1. MapReduce-системыИзначально они
были разработаны в Google для обработки больших объемов данных (веб-краулер). MapReduce не использует фиксированную модель данных или язык запросов, они выполняют пользовательские операции map и reduce. Открытой версией MapReduce стал Hadoop, который сейчас не очень популярен из-за низкой производительности и заменяется более современными платформами аля
Apache Spark или просто СУБД.
2. Key-Value хранилищаУ них максимально простая модель данных: пары "ключ-значение". Они используются для задач кэширования (
Memcached,
Redis) или хранения сессий. Возможности в модели ограничены - нет индексов или операций join, что усложняет применение для сложных приложений. Многие KV-хранилища (например,
DynamoDB,
Aerospike) эволюционировали в более функциональные системы с поддержкой частичной структуры (JSON). Среди популярных встроенных k/v решений популярны
LevelDB и
RocksDB.
3. Документные базы данныхОни хранят данные в виде документов (например, в формате JSON). Изначально получили популярность благодаря простоте интеграции с веб-приложениями (например,
MongoDB), предлагая подход schema on read. Интресно, что к 2020-м годам большинство документных СУБД добавили SQL-подобные интерфейсы и поддержку ACID-транзакций, а иногда и schema on write.
4. Column-Family базы данных (wide columns)По-факту, это упрощенная версия документной модели с ограниченной вложенностью.
Начиналось все с Google BigTable, а в миру есть open source реализация в виде
Apache Cassandra. Изначально в Cassandra не было вторичных индексов и транзакций. Но по мере развития они появились (но там все
очень интересно)
5. Поисковые движкиОни нужны для полнотекстового поиска (
Elasticsearch,
Apache Solr). Поддерживают индексацию текста, но ограничены в транзакционных возможностях. Реляционные СУБД также предлагают встроенный полнотекстовый поиск, но с менее удобным API.
6. Базы данных для массивовОни предназначены для работы с многомерными массивами, например, научные данные (
SciDB,
Rasdaman). Ниша ограничена специфическими областями применения: геоданные, изучение генома.
7. Векторные базы данныхИспользуются для хранения эмбеддингов из машинного обучения (
Pinecone,
Milvus). Основное применение — поиск ближайших соседей в высокоразмерных пространствах. Реляционные СУБД уже начали добавлять поддержку векторных индексов.
8. Графовые базы данныхМоделируют данные как графы (узлы и связи). Примеры:
Neo4j для OLTP-графов,
TigerGraph для аналитики. Большинство графовых задач можно реализовать на реляционных СУБД с помощью SQL/PGQ (новый стандарт
SQL:2023).
Общие выводы- Большинство нереляционных систем либо занимают нишевые рынки, либо постепенно сближаются с реляционными СУБД.
- SQL остается основным языком запросов благодаря своей гибкости и поддержке современных приложений.
- Реляционные СУБД продолжают развиваться и интегрировать новые возможности (например, JSON, векторные индексы), что делает специализированные системы менее конкурентоспособными.
В
продолжении поста будет про архитектуру баз данных.
#Data #Architecture #Software #DistributedSystems
