Типы баз данных: 16 видов и когда какой выбирать

Какие бывают типы баз данных?

Базы данных делятся на типы по тому, как они хранят данные и какие запросы отвечают быстро: таблицы со связями, документы, пары ключ-значение, графы, временные ряды, векторы и так далее. Одни из них повседневные, другие узкоспециализированные, но инженеру, который строит продакшн-системы, полезно понимать все.

В статье разобраны 16 типов: реляционные, документные, ключ-значение, ширококолоночные, графовые, временных рядов, геопространственные, векторные, поисковые движки, in-memory, распределённый SQL, встраиваемые, колоночные, data lakehouse, объектное хранилище и реестровые.

По каждому типу даны:

• определение одним абзацем и как это работает;
• аналогия из реальной жизни;
• плюсы и минусы;
• когда его использовать и какие продукты популярны.

Что такое реляционная база данных?

Реляционная база данных хранит данные в таблицах со строками и столбцами и связывает эти таблицы через общие ключи. Каждая строка имеет одинаковую структуру, а ключи скрепляют таблицы между собой.

• Модель: таблицы и связи
• Язык: SQL
• Примеры: PostgreSQL, MySQL

Как работает реляционная база данных?

Структуру таблиц объявляют заранее на языке структурированных запросов (SQL).

Например, строка клиента содержит идентификатор, имя и email. Заказы живут в отдельной таблице и содержат идентификатор клиента, а база сопоставляет их по этому столбцу в операции под названием join.

Транзакции объединяют несколько изменений в одну единицу: деньги переходят между двумя счетами полностью, либо обе строки остаются как были. Эта гарантия называется ACID (атомарность, согласованность, изолированность, устойчивость). Именно поэтому банки и магазины работают на реляционных движках уже пятьдесят лет. PostgreSQL к тому же выходит за рамки модели через расширения и добавляет в ту же базу геоданные и векторный поиск.

Одна схема и один набор правил: каждое приложение, которое подключается к базе, получает одинаковый ответ.

Аналогия: склад со строгой формой приёмки

На каждой паллете одинаковые поля этикетки, поэтому любой водитель найдёт любую паллету, просто считав код. Измените форму — и придётся переклеивать этикетки на всём складе.

Плюсы и минусы реляционной базы данных

Плюсы. Корректность данных достаётся бесплатно: join'ы, ограничения и транзакции работают из коробки.

Минусы. Фиксированная схема сопротивляется изменениям: добавление столбца в большую таблицу может заблокировать её на время выполнения. Пропускная способность записи упирается в потолок одной машины, и поднять его можно только ручным шардированием.

Когда использовать реляционную базу данных?

Заказы, платежи, складские остатки, пользователи и любые данные с реальными связями между сущностями. PostgreSQL и MySQL закрывают большую часть таких задач.

В пару берут in-memory кэш и распределённый SQL: они подхватывают нагрузку, когда чтения и записи перерастают одну машину.

Что такое документная база данных?

Документная база данных хранит каждую запись как один самодостаточный документ, как правило в формате JSON (JavaScript Object Notation). Два документа в одной коллекции могут иметь разный набор полей.

• Модель: документы JSON
• Схема: гибкая
• Примеры: MongoDB, Couchbase

Как работает документная база данных?

У одного товара есть размер обуви, у другого — разрешение экрана и срок гарантии. База хранит каждый документ целиком, поэтому одно чтение возвращает весь товар со всеми вложенными полями без единого join'а.

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

Свобода живёт в схеме, а скорость по-прежнему обеспечивает дисциплинированное индексирование. Измените поля у одного товара — остальная коллекция останется без изменений.

Аналогия: картотечный шкаф с папками дел

В каждой папке лежат все страницы по одному делу, поэтому на любой вопрос о нём отвечает одна вынутая папка. Никто не проверяет, одинаковые ли страницы лежат в разных папках.

Плюсы и минусы документной базы данных

Плюсы. Каждая запись может иметь собственную структуру. Это подходит для данных, форму которых никто не может определить заранее.

Минусы. Копии одного и того же факта расползаются по документам и расходятся между собой, а связи между документами ложатся на код приложения. Схема открыта, поэтому некорректные записи тихо попадают в продакшн и всплывают спустя месяцы.

Проверяйте структуру на уровне базы данных: гибкость, которую вы хотите в первый год, к третьему году превращается в хаос, который достанется вам в наследство.

Когда использовать документную базу данных?

Каталоги, профили пользователей, контент и полезная нагрузка событий — там, где записи различаются между собой и читаются целиком. Популярный выбор — MongoDB и Couchbase.

В пару берут поисковый движок для текстовых запросов. Если каждое чтение и так идёт по идентификатору, хватит хранилища ключ-значение.

Что такое хранилище ключ-значение?

Хранилище ключ-значение (key-value store) сохраняет значение под уникальным ключом и возвращает его за один поиск. Ключ — единственный путь к данным.

• Модель: ключ → значение
• Сильная сторона: самое быстрое чтение по ключу
• Примеры: Redis, Memcached

Как работает хранилище ключ-значение?

Запросите один ключ, и хранилище ответит за один переход: без сканирования и без планировщика запросов на пути. Хранилище хеширует каждый ключ на конкретный узел, поэтому добавление узлов делит пространство ключей и линейно поднимает ёмкость. Многие KV-хранилища умеют задавать время жизни записи (TTL), чтобы закэшированные данные истекали сами.

В этой нише доминирует Redis.

Аналогия: гардероб

Вы сдаёте пальто и получаете номерок, по номерку пальто вернут за секунды. Но у гардеробщика нет способа найти все коричневые пальто в зале.

Плюсы и минусы хранилища ключ-значение

Плюсы. Самый быстрый путь чтения и масштабирование простым добавлением узлов.

Минусы. Любой поиск не по ключу означает полный проход по данным, а вторичные индексы ограничены или отсутствуют вовсе. Один популярный ключ направляет весь свой трафик на один узел: «горячий» ключ перегружает одну машину, пока остальные простаивают.

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

Когда использовать хранилище ключ-значение?

Сессии, корзины покупок, feature-флаги и счётчики rate limit — там, где идентификатор известен уже в момент чтения. Redis — стандарт индустрии.

В пару берут реляционную базу данных: она хранит истину, а хранилище ключ-значение держит быструю копию.

Что такое ширококолоночная база данных?

Ширококолоночное хранилище (wide-column store) распределяет строки по множеству узлов, и каждая строка хранит только те столбцы, которые ей нужны. Это модель для петабайтов данных и огромных объёмов записи.

• Модель: партиции строк с переменным набором столбцов
• Сильная сторона: запись в масштабе кластера
• Примеры: Cassandra, HBase

Как работает ширококолоночная база данных?

Первичный ключ выполняет двойную работу:

• его первая часть (ключ партиционирования) определяет, на каком узле хранится строка;
• вторая часть (ключ кластеризации) определяет порядок строк внутри партиции.

Если оба выбраны хорошо, запрос читает одну партицию на одном узле. Именно так ширококолоночные хранилища отвечают за миллисекунды, храня при этом петабайты данных.

У записи тоже быстрый путь: она дописывается в commit log и таблицу в памяти, а затем сбрасывается в отсортированные файлы на диске. Для обновления строки ничего не нужно искать по диску.

Подберите ключ правильно — и чтение затронет один узел. Ошибитесь — и оно затронет все.

Аналогия: стадион с пронумерованными воротами

На вашем билете указаны ворота, поэтому вы проходите прямо внутрь, пока шестьдесят тысяч человек движутся одновременно. Придите без номера ворот — и будете обходить здание по кругу.

Плюсы и минусы ширококолоночной базы данных

Плюсы. Выдерживает объёмы записи, которые не переживёт ни одна отдельная машина, и остаётся доступной при отказе узлов.

Минусы. Здесь моделируют запросы раньше, чем данные, поэтому вопрос, который никто не предвидел, требует второй таблицы и второй копии данных. Удаления оставляют после себя маркеры (tombstones), пока их не уберёт компакция. Repair, компакция и замена узлов — реальная эксплуатационная работа.

Выпишите все нужные запросы до того, как спроектируете ключ: позже модель будет сопротивляться новым вопросам.

Когда использовать ширококолоночную базу данных?

История сообщений, ленты активности и телеметрия устройств при объёмах записи, которые одна машина не потянет. Здесь лидируют Cassandra и HBase.

Если данные помечены временем, посмотрите на базу временных рядов: она даёт тот же масштаб при куда меньшем объёме моделирования.

Что такое графовая база данных?

Графовая база данных хранит данные как узлы и рёбра между ними, а на вопросы отвечает, проходя по этим рёбрам. Связь сохраняется явно, поэтому переход по ней почти ничего не стоит.

• Модель: узлы и рёбра
• Языки: Cypher, Gremlin
• Примеры: Neo4j

Как работает графовая база данных?

В реляционной базе поиск друзей ваших друзей означает join таблицы самой с собой на каждый шаг, и каждый шаг умножает объём работы. Графовая база хранит прямой указатель от каждого узла к его соседям, поэтому шаг — это просто переход по указателю, и глубина обхода перестаёт иметь значение.

Языки запросов вроде Cypher и Gremlin позволяют описать нужную форму связей, а движок сам её прослеживает.

Аналогия: схема метро

Вы прочерчиваете маршрут пальцем, не читая ни одного расписания.

Плюсы и минусы графовой базы данных

Плюсы. Отвечает на вопросы о связях, а запросы читаются так же, как звучал сам вопрос.

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

Берите графовую базу, когда продукт — это сами связи.

Когда использовать графовую базу данных?

Мошеннические сети, рекомендации, социальные графы, цепочки прав доступа и топология сетей. Популярный выбор — Neo4j.

В пару берут реляционную базу данных: она хранит записи, а граф хранит связи между ними.

Что такое база данных временных рядов?

База данных временных рядов (time-series database) хранит измерения, помеченные временем, и организует их по интервалам. Данные поступают в хронологическом порядке, а старые измерения почти никогда не меняются.

• Модель: метка времени + значение + теги
• Сильная сторона: миллионы точек в секунду
• Примеры: InfluxDB, TimescaleDB, Prometheus

Как работает база данных временных рядов?

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

Близкие по времени измерения часто похожи друг на друга, и базы временных рядов сжимают их очень сильно. Правила хранения (retention) автоматически удаляют старые данные, а даунсэмплинг заменяет детальные точки сводками. Можно хранить каждое измерение за неделю и только часовые средние за год.

Старые данные сжимаются или удаляются по расписанию, и база остаётся в пределах запланированного размера.

Аналогия: судовой журнал

Каждая запись идёт на следующей строке рядом со временем, и никто не стирает вчерашний день.

Плюсы и минусы базы данных временных рядов

Плюсы. Принимает миллионы точек в секунду и мгновенно отвечает на запросы по диапазонам времени.

Минусы. Редактирование или удаление отдельных точек противоречит самой конструкции, поэтому исправления даются неловко. Теги с неограниченным числом значений (например, идентификатор пользователя на каждом показании) раздувают индекс и съедают память.

Держите значения тегов немногочисленными и ограниченными.

Когда использовать базу данных временных рядов?

Метрики, показания сенсоров, биржевые цены и всё, что строят на графике во времени. Здесь лидируют InfluxDB, TimescaleDB и Prometheus.

В пару берут колоночную базу данных: она забирает долгосрочный анализ, когда сырые точки уже свёрнуты в сводки.

Что такое геопространственная база данных?

Геопространственная база данных индексирует точки и фигуры на карте и отвечает на вопросы о расстоянии, вхождении и пересечении. Местоположение превращается из двух чисел в строке в то, по чему можно делать запрос.

• Индексы: R-дерево, geohash
• Запросы: «в радиусе», «внутри зоны», «пересекает»
• Примеры: PostGIS

Как работает геопространственная база данных?

Обычный индекс сортирует значения вдоль одного измерения, а у координат их два. Пространственные индексы решают эту задачу по-разному:

• R-деревья группируют близкие точки и фигуры в ограничивающие прямоугольники;
• Geohash кодирует широту и долготу в иерархические ячейки сетки, поэтому у близких локаций часто общий префикс.

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

Вашему коду не нужно перебирать каждую координату и считать расстояния самостоятельно.

Аналогия: прозрачная сетка поверх карты

Сначала вы находите нужный квадрат, а затем смотрите только внутри него, а не сканируете весь лист.

Плюсы и минусы геопространственной базы данных

Плюсы. Расстояние и вхождение становятся быстрыми запросами.

Минусы. Фигуры тяжело хранить и медленно переиндексировать при изменении. Земля круглая, а карты плоские, поэтому любая проекция вносит погрешность. Сравнение данных, записанных в двух разных системах координат, даёт ответы, которые выглядят правильными, но таковыми не являются.

Выберите одну систему координат в самом начале: конвертация позже означает переписывание каждой сохранённой фигуры.

Когда использовать геопространственную базу данных?

Зоны доставки, поиск ближайших магазинов, подбор поездок, карты и логистика. PostGIS даёт PostgreSQL полный набор инструментов, у MongoDB, Elasticsearch и Redis есть облегчённые версии.

Чаще всего геоданные не выносят в отдельную систему, а встраивают в реляционную базу, которая у вас уже работает.

Что такое векторная база данных?

Векторная база данных хранит эмбеддинги — списки чисел, описывающие смысл текста, изображения или звука, — и находит векторы, ближайшие к вашему запросу. Поиск идёт по схожести, а не по точному совпадению.

• Модель: эмбеддинги
• Индекс: ANN, HNSW
• Примеры: pgvector, Pinecone, Milvus, Qdrant

Как работает векторная база данных?

AI-модель превращает текст, изображения или аудио в векторы: списки чисел, представляющие их признаки или смысл. Похожие объекты получают векторы, близкие друг к другу в этом математическом пространстве.

Сравнивать вектор запроса с миллионами сохранённых векторов по одному слишком медленно. Поэтому векторные базы используют индексы приближённого поиска ближайших соседей (ANN), например Hierarchical Navigable Small World (HNSW).

HNSW ищет по графу близких векторов, а не проверяет каждый вектор. Поиск становится гораздо быстрее ценой компромисса: иногда он пропускает часть по-настоящему ближайших совпадений.

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

Аналогия: библиотекарь, который расставляет книги по теме

Полки организованы по смыслу, а не по алфавиту названий. Вы примерно описываете, что хотите, и библиотекарь подводит вас к нужной полке.

Плюсы и минусы векторной базы данных

Плюсы. Находит семантические совпадения, которые пропускает поиск по ключевым словам. На этом держится retrieval во многих приложениях с языковыми моделями (RAG).

Минусы. Поиск приближённый. Индекс настраивают, балансируя полноту (recall) и задержку: более тщательный поиск находит больше настоящих соседей, но занимает больше времени.

Векторы занимают много места в хранилище и памяти, особенно на миллионах объектов. Оценки схожести говорят, какие векторы близки, но не объясняют, почему результат совпал, в форме, понятной пользователю.

Отдельная проблема — смена модели эмбеддингов. Новая модель даёт другое векторное пространство, поэтому придётся заново сгенерировать эмбеддинги для всего корпуса и перестроить индекс.

Храните исходный текст рядом с каждым вектором: он понадобится для retrieval, цитирования и будущего пересчёта эмбеддингов.

Когда использовать векторную базу данных?

Семантический поиск, рекомендации, дедупликация и retrieval для языковых моделей. Популярные варианты — pgvector, Pinecone, Milvus и Qdrant.

В пару берут поисковый движок: гибридный поиск по ключевым словам и векторам вместе выигрывает у каждого из них по отдельности.

Что такое поисковый движок как база данных?

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

• Индекс: инвертированный
• Ранжирование: BM25
• Примеры: Elasticsearch, OpenSearch, Meilisearch, Typesense

Как работает поисковый движок?

1. Обработка текста. Движок разбивает текст на токены. В зависимости от анализатора он приводит слова к нижнему регистру, убирает частые служебные слова и сводит слова к основе. Так «running shoes» совпадёт с «run shoe».
2. Инвертированный индекс. Вместо сканирования каждого документа движок хранит список документов для каждого термина. Поиск сразу переходит к нужным спискам.
3. Ранжирование. Функция вроде BM25 оценивает подходящие документы по частоте термина в документе и редкости термина среди всех документов.
4. Улучшение выдачи. Движок добавляет устойчивость к опечаткам, синонимы, подсветку совпадений и фасетные счётчики для фильтров.

Аналогия: предметный указатель в конце учебника

Найдите слово и получите список страниц, упорядоченный так, что полезные идут первыми.

Плюсы и минусы поискового движка

Плюсы. Быстрое ранжирование по релевантности, устойчивость к опечаткам и фасетный поиск.

Минусы. Поисковый индекс обычно копия данных из основной базы. Если пайплайн синхронизации падает или отстаёт, индекс устаревает. Обновления идут почти в реальном времени, поэтому новым и изменённым данным нужно время, чтобы появиться в выдаче.

Поисковые кластеры потребляют много памяти. В зависимости от маппингов, анализаторов и сохранённых полей индекс может оказаться больше исходных данных.

Относитесь к поисковому индексу как к производной копии, а не к источнику истины. Храните исходные данные отдельно, чтобы при необходимости безопасно пересобрать индекс целиком.

Когда использовать поисковый движок?

Поиск по товарам, исследование логов, документация — везде, где люди вводят слова и ждут ранжированные ответы. Доминируют Elasticsearch и OpenSearch, а Meilisearch и Typesense обслуживают развёртывания поменьше.

В пару берут реляционную или документную базу: она хранит запись, а поисковый движок хранит индекс.

Что такое in-memory база данных?

In-memory база данных держит рабочий набор данных в оперативной памяти и использует диск как резервное, а не основное хранилище. Обращение к диску исчезает из обычного пути чтения.

• Хранение: RAM
• Задержка: миллисекунда и меньше
• Примеры: Redis, Memcached

Как работает in-memory база данных?

RAM возвращает данные за десятки наносекунд, а быстрый SSD — за десятки микросекунд. Разница примерно в три порядка.

Некоторые in-memory базы, например Redis, сохраняют данные на диск через периодические снимки или append-only лог (AOF). После перезапуска Redis восстанавливает по ним своё состояние. Memcached изначально спроектирован эфемерным.

In-memory базы дают полезные структуры данных сверх простого кэширования:

• счётчики для rate limit;
• отсортированные множества для таблиц лидеров;
• стримы для обработки событий и очередей.

Аналогия: инструменты на верстаке, а не в сарае

Те же инструменты, только за ними не нужно выходить на улицу.

Плюсы и минусы in-memory базы данных

Плюсы. Ответ за миллисекунду или быстрее.

Минусы. Гигабайт RAM стоит в разы дороже гигабайта диска, поэтому потолок задаёт бюджет. Сбой теряет всё, что записано после последнего снимка. Когда данные перерастают память, политика вытеснения решает, каким пользователям достанется медленная страница.

Решите, что произойдёт при заполнении памяти, до того как она заполнится: вытеснение — продуктовое решение в костюме инфраструктурного.

Когда использовать in-memory базу данных?

Кэши, таблицы лидеров, хранилища сессий, ограничители частоты запросов и лёгкие очереди. Популярный выбор — Redis и Memcached.

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

Что такое распределённая SQL-база данных?

Распределённая SQL-база данных (distributed SQL) раскладывает реляционную базу по множеству машин и при этом сохраняет транзакции, join'ы и SQL. Вы получаете гарантии SQL сразу на кластере.

• Консенсус: Raft
• Транзакции: распределённые (2PC)
• Примеры: CockroachDB, TiDB, YugabyteDB

Как работает распределённая SQL-база данных?

База делит строки на диапазоны и распределяет их по узлам. У каждого диапазона несколько реплик, и протокол консенсуса вроде Raft удерживает их в согласии по поводу записей. Если один узел отказывает, данные остаются на другой реплике.

Когда транзакция затрагивает данные на нескольких узлах, база координирует её двухфазным коммитом (2PC), консенсусом и управлением метками времени. Так распределённые SQL-базы обеспечивают сериализуемые транзакции даже по географически распределённым данным.

Многие распределённые SQL-базы совместимы с протоколом PostgreSQL или MySQL. Существующий SQL, драйверы и инструменты требуют меньше изменений, чем переход на другую модель данных.

Аналогия: банк с отделениями в каждом городе

Один счёт, один баланс, и каждое отделение соглашается с ним до того, как снятие средств пройдёт.

Плюсы и минусы распределённой SQL-базы данных

Плюсы. Горизонтальное масштабирование без отказа от транзакций.

Минусы. Согласование стоит времени: запись, которая затрагивает три узла, идёт дольше записи на один. Кластеру нужно минимум три узла и реальное операционное внимание. Управляемые версии стоят намного дороже одного сервера, а экосистема моложе, чем у PostgreSQL.

Держите связанные строки в одном диапазоне: транзакция на один узел всегда лучше транзакции на пять.

Когда использовать распределённую SQL-базу данных?

Глобальные приложения, запись из нескольких регионов и нагрузки, которые переросли одну реляционную машину. Популярные варианты — CockroachDB, TiDB и YugabyteDB.

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

Что такое встраиваемая база данных?

Встраиваемая база данных (embedded database) работает внутри вашего приложения как библиотека, а вся база хранится как обычный файл. Нет отдельного сервера, порта и сетевого соединения.

• Развёртывание: библиотека + файл
• Задержка сети: нулевая
• Примеры: SQLite, DuckDB, RocksDB

Как работает встраиваемая база данных?

Запрос превращается в локальный вызов функции вместо сетевого round trip'а. Это снижает задержку и убирает инфраструктуру, которая нужна для отдельного сервиса базы данных.

• SQLite работает внутри телефонов, браузеров и десктопных приложений, а вся база лежит в одном файле.
• DuckDB переносит ту же модель на аналитику: колоночные запросы над локальными данными без кластера.

RocksDB и LevelDB находятся уровнем ниже: это встраиваемые движки хранения внутри приложений и более крупных баз данных.

Аналогия: блокнот в кармане

Вы открываете его где угодно, и больше никому не нужно при этом присутствовать.

Плюсы и минусы встраиваемой базы данных

Плюсы. Нулевая настройка, нулевая сетевая задержка и один файл для резервного копирования.

Минусы. Хорошо обслуживает один процесс и плохо — многие:

• параллельные писатели встают в очередь за единой блокировкой;
• репликации и удалённого доступа по умолчанию нет;
• файл живёт на диске одной машины, поэтому отказ машины означает потерю данных.

Используйте её там, где данные принадлежат одному устройству, и переходите на сервер, как только двум машинам понадобятся одни и те же строки.

Когда использовать встраиваемую базу данных?

Мобильные приложения, десктопные инструменты, edge-устройства, хранилище браузера и локальная аналитика.

В пару берут объектное хранилище или серверную базу: туда уходит копия с устройства для синхронизации.

Что такое колоночная база данных?

Колоночная база данных (columnar database) хранит каждый столбец отдельно, поэтому запрос читает только те столбцы, которые в нём указаны. Это раскладка под аналитику: несколько столбцов из миллиардов строк.

• Нагрузка: аналитика (OLAP)
• Сильная сторона: агрегаты и сжатие
• Примеры: ClickHouse, DuckDB, облачные аналитические хранилища

Как работает колоночная база данных?

Строковое хранилище держит все значения одной строки вместе. Запрос вроде SUM(revenue) по миллиарду строк прочитает с диска множество ненужных столбцов.

Колоночное хранилище держит вместе значения одного столбца. Тот же запрос читает только revenue и пропускает остальное.

Такая раскладка даёт два преимущества:

• Лучшее сжатие. Значения одного столбца обычно одного типа и с повторяющимися паттернами, их проще сжимать.
• Векторизованное выполнение. База обрабатывает пачку значений столбца за раз, а не строки по одной.

Чтение меньшего числа байт снижает I/O, и большие аналитические запросы идут значительно быстрее.

Аналогия: таблица, которую читают сверху вниз

Чтобы просуммировать один столбец, вы проводите по нему пальцем сверху вниз, а остальные сорок столбцов остаются нетронутыми.

Плюсы и минусы колоночной базы данных

Плюсы. Сканирует и агрегирует со скоростью, недостижимой для строковых хранилищ, и сжимает данные настолько, что это заметно в счёте за хранение.

Минусы. Получение или обновление одной строки идёт медленно, потому что строка разбросана по множеству файлов столбцов. Загрузка работает пачками, а не по одной записи. Транзакции ограничены или отсутствуют.

Держите колоночную базу ниже по потоку от транзакционной и загружайте данные пачками, а не построчно.

Когда использовать колоночную базу данных?

Дашборды, отчётность, продуктовая аналитика и любой запрос, который агрегирует миллионы строк. ClickHouse и облачные аналитические хранилища (DWH) используют колоночное хранение, а DuckDB приносит его в локальную встраиваемую базу.

Выше по потоку стоит реляционная база данных: она обрабатывает записи, которые колоночная сводит в отчёты.

Что такое data lakehouse?

Data lakehouse добавляет табличные правила и транзакции к обычным файлам, которые лежат в объектном хранилище. Одни и те же данные служат и аналитике, и машинному обучению.

• Форматы: Apache Iceberg, Delta Lake, Apache Hudi
• Файлы: Parquet в объектном хранилище
• Движки: Spark, Trino, DuckDB

Как работает data lakehouse?

Традиционный data lake хранит файлы вроде Parquet в дешёвом объектном хранилище. Но сами по себе файлы не дают гарантий уровня базы данных о том, какие из них принадлежат таблице в конкретный момент.

Табличные форматы Apache Iceberg, Delta Lake и Apache Hudi добавляют поверх файлов слой метаданных. Он отслеживает, какие файлы составляют каждую версию таблицы, и даёт:

• атомарные записи: читатели видят завершённое обновление, а не частично записанную таблицу;
• эволюцию схемы: схема таблицы меняется вместе с данными;
• time travel: можно запросить более раннюю версию таблицы.

С этими форматами работают сразу несколько движков: Spark, Trino, DuckDB и облачные аналитические хранилища. Разные движки читают одни и те же данные без отдельной копии для каждого. Хранение и вычисления разделены: файлы лежат в объектном хранилище, а движки обрабатывают их по мере необходимости.

Spark пишет таблицу, Trino её читает, и одни и те же данные обслуживают обоих.

Аналогия: каталожная картотека для склада коробок

Коробки никуда не переместились, но теперь все согласны, какие из них составляют набор.

Плюсы и минусы data lakehouse

Плюсы. Дешёвое хранение, открытые форматы и свобода от вендора, который удерживает ваши данные.

Минусы. Собирать все части приходится самостоятельно, и за каталогом, движком и табличным форматом нужно следить отдельно. С каждой записью копятся мелкие файлы, которые тормозят запросы, пока их не скомпактируют. Задержка запросов измеряется секундами там, где настроенное хранилище данных (data warehouse) отвечает за миллисекунды.

Компактируйте мелкие файлы по расписанию: формат тихо деградирует, пока никто не смотрит.

Когда использовать data lakehouse?

Крупные аналитические ландшафты, пайплайны машинного обучения и все, кому нужна одна-единственная копия данных. Форматы, которые стоит знать, — Apache Iceberg и Delta Lake.

В пару берут колоночные движки и объектное хранилище: первые дают скорость запросов, второе хранит байты.

Что такое объектное хранилище?

Объектное хранилище (object storage) сохраняет целые файлы под одним ключом: без строк, без запросов и практически без ограничения размера. Это самый дешёвый надёжный дом для больших файлов.

• Модель: ключ → файл + метаданные
• API: S3
• Примеры: S3-совместимые хранилища облачных провайдеров, MinIO

Как работает объектное хранилище?

Каждый объект состоит из трёх частей:

• данные: сам файл — изображение, видео, бэкап или файл Parquet;
• метаданные: информация об объекте, например тип содержимого или пользовательские атрибуты;
• ключ: уникальное имя, по которому объект находят.

Пространство ключей плоское. Ключ вроде photos/2026/image.png выглядит как путь по папкам, но S3 и похожие системы считают / просто частью ключа. Инструменты используют эти префиксы, чтобы показать структуру, похожую на папки.

Облачные провайдеры хранят избыточные копии объектов по своей инфраструктуре и обеспечивают высокую устойчивость. Есть «холодные» уровни хранения: хранить дешевле, извлекать дольше и дороже. Это подходит для бэкапов и архивов.

Аналогия: камера хранения багажа

Вы получаете ключ от того, что сдали, а камера хранения никогда не спрашивает, что внутри сумки.

Плюсы и минусы объектного хранилища

Плюсы. Самое дешёвое надёжное хранение больших файлов при любом объёме, и оно растёт без планирования ёмкости.

Минусы. Оно не отвечает ни на какие вопросы о содержимом, а изменение одного байта переписывает весь объект. Время до первого байта намного больше, чем у локального диска. Извлечение из холодных уровней и между регионами стоит и денег, и минут.

Храните байты здесь, а указатель на них — в своей базе данных. Так запросы остаются там, где им место.

Когда использовать объектное хранилище?

Изображения, видео, бэкапы, логи, веса моделей и файлы под lakehouse. S3 популяризировал эту модель. Похожие сервисы есть у всех крупных облачных провайдеров, а MinIO даёт self-hosted-хранилище с поддержкой S3 API.

В пару берут реляционную базу данных, которая хранит ключи и метаданные: что представляет собой каждый объект.

Что такое реестровая база данных (ledger)?

Реестровая база данных (ledger database) только дописывает записи и никогда их не редактирует, поэтому сохраняет проверяемую историю каждого изменения. Прошлое нельзя незаметно переписать.

• Модель: append-only журнал
• Защита: криптографические хеши
• Примеры: immudb, темпоральные таблицы

Как работает реестровая база данных?

В обычной базе обновление заменяет предыдущее значение, если историю не хранить отдельно. Реестровая база записывает каждое изменение как новую запись, и предыдущие версии остаются доступны.

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

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

Категорию создали специализированные ledger-базы вроде immudb и облачные ledger-сервисы, а темпоральные таблицы в PostgreSQL и SQL Server закрывают немалую часть тех же задач.

Аналогия: переплетённая бухгалтерская книга

Исправления идут новой строкой с датой, а старая строка остаётся ровно там, где была.

Плюсы и минусы реестровой базы данных

Плюсы. Защита от незаметного вмешательства и полный аудиторский след без дополнительной работы.

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

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

Когда использовать реестровую базу данных?

Финансовые записи, аудиторские следы для регуляторов, происхождение товаров в цепочке поставок и системы учёта.

В пару берут реляционную базу данных: она обслуживает текущее состояние, а реестр хранит историю.

Сравнительная таблица типов баз данных

Ниже все 16 типов в одной таблице: как хранят данные, для чего их берут и какие продукты популярны.

Как выбрать базу данных для проекта?

Начните с реляционной базы данных. Она справляется с большей частью данных приложения и даёт транзакции, ограничения и гибкие запросы. Следующую базу добавляйте только тогда, когда её требует конкретный паттерн доступа.

Каждая специализированная база решает конкретную задачу, но добавляет ещё одну систему, которую нужно эксплуатировать, мониторить, резервировать и понимать.

Какие ошибки чаще всего допускают при выборе базы данных?

• Считают поисковый индекс источником истины.
• Забывают об инвалидации кэша.
• Выбирают документную базу, чтобы не проектировать схему, а потом копят рассогласованные документы.
• Заводят неограниченные теги с высокой кардинальностью в базе временных рядов.
• Проектируют ширококолоночные таблицы раньше, чем определены запросы.
• Гоняют тяжёлую аналитику прямо на продакшн-реляционной базе.
• Эксплуатируют пять баз данных там, где задачу решили бы две.

Выбирайте минимальное число баз данных, которое хорошо отвечает на ваши запросы. Добавляйте следующую только тогда, когда реальное требование заслуживает для неё места. Начинайте с малого.

Частые вопросы о типах баз данных

Источники

• E. F. Codd, A Relational Model of Data for Large Shared Data Banks (1970). Статья, на которой держится вся реляционная модель.
• Giuseppe DeCandia и др., Dynamo: Amazon's Highly Available Key-value Store (2007).
• Fay Chang и др., Bigtable: A Distributed Storage System for Structured Data (2006). Источник концепции ширококолоночных хранилищ.
• James C. Corbett и др., Spanner: Google's Globally-Distributed Database (2012).
• Daniel Abadi, Consistency Tradeoffs in Modern Distributed Database System Design (IEEE Computer, 2012). Модель PACELC.
• Michael Armbrust и др., Lakehouse: A New Generation of Open Platforms that Unify Data Warehousing and Advanced Analytics (CIDR 2021).
• Yury Malkov и Dmitry Yashunin, Efficient and Robust Approximate Nearest Neighbor Search Using Hierarchical Navigable Small World Graphs (2016). Индекс, на котором держится векторный поиск.
• Документация SQLite, Appropriate Uses For SQLite.
• Документация Apache Cassandra, Storage engine and the write path.
• Документация PostgreSQL, Indexes.