Виды баз данных: от реляционных до новейших NoSQL и не только

Сегодня поговорим про базы данных – их разновидности, различия и для каких задач каждая подходит. Баз данных сейчас столько, что глаза разбегаются: от классических реляционных SQL-систем до модных NoSQL-решений вроде ClickHouse, и дальше – ключ-значение, документных, графовых, колоночных... Давайте разбираться, зачем нам столько разных баз и где какую лучше применять (включая даже, где удобнее хранить деревья, JSON или файлы).

Кстати, маленькое историческое отступление: первые базы данных появились ещё в 60-х. Например, для программы "Аполлон" NASA и IBM в 1968 году разработали IMS – иерархическую базу данных, чтобы следить за миллионами деталей ракеты Saturn V. Она хранила данные в виде дерева (родитель-потомок). Так что иерархия – самый первый тип БД! Но настоящая революция случилась в 1970-х, когда доктор Эдгар Кодд придумал реляционную модель данных. С тех пор и по сей день реляционные базы доминируют во многих областях. Однако требования ИТ росли, появился интернет, большие данные – и появились новые виды баз данных, заточенные под конкретные задачи. Сейчас мы живём в эпоху изобилия БД: каждая со своим характером и суперспособностями. Поехали!

Виды баз данных: от реляционных до новейших NoSQL и не только

Реляционные базы данных (SQL)

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

Главная сила реляционных баз – SQL (Structured Query Language), язык запросов, позволяющий делать сложные выборки: соединять таблицы (JOIN), фильтровать, агрегировать (SUM/COUNT), сортировать и пр. Кроме того, такие базы гарантируют надежность транзакций по принципам ACID (атомарность, согласованность, изоляция, долговечность). Проще говоря, реляционные СУБД отлично сохраняют целостность данных: либо всё внутри транзакции выполнится, либо ничего, и данные не противоречат друг другу. Поэтому они незаменимы в банковских системах, бухгалтерии, на складе – везде, где важна точность и консистентность.

Однако за строгую структуру и надежность приходится платить гибкостью и масштабируемостью. Добавить новый столбец – это миграция схемы, нужно аккуратно обновлять всю таблицу. А если данных становится очень много (миллионы пользователей, миллиард событий), то масштабировать классическую SQL-базу на десятки серверов непросто. Это мотивировало появление новых решений, о которых поговорим дальше. Но и SQL-мир не стоит на месте: появились распределённые реляционные базы (NewSQL), совмещающие привычный SQL с горизонтальным масштабированием на много узлов. Примеры – Google Spanner или CockroachDB, которые умеют работать в распределённой среде, сохраняя при этом транзакционность и консистентность (Google Spanner вообще использует атомные часы, чтобы согласовать данные по всему миру – wow!).

Для каких задач реляционные БД? Для структурированных данных с четкими связями. Если у вас банковские счета, инвентаризация товаров, учет пользователей – скорее всего, нужна реляционная БД. Они также могут выполнять сложные аналитические запросы (OLAP), хотя специализированные колоночные базы (о них позже) делают это быстрее. Деревья и иерархии можно хранить и в SQL (например, добавить поле parent_id для родителя и строить рекурсивные запросы), но это бывает неудобно. Нет встроенного типа "дерево", приходится извращаться с JOIN-ами или рекурсией. JSON? Раньше со сложными вложенными данными реляционные СУБД справлялись плохо – нужно было разбивать JSON на связанные таблицы. Но сейчас многие (PostgreSQL, MySQL) поддерживают JSON-поля, позволяя хранить полуструктурированные данные внутри таблиц и даже индексировать их. То есть граница между SQL и NoSQL чуть стерлась: вы можете в PostgreSQL держать и табличные данные, и JSON-документы вместе. Но всё равно, если основной формат данных – гибкий JSON с разными полями для каждой записи – зачастую удобнее документная база (см. ниже). Файлы (картинки, видео) можно хранить как BLOB (большие двоичные объекты) в колонках, но это не лучшая идея: базы не заточены под раздачу больших файлов, это снижает их производительность и раздувает бэкапы. Обычно файлы хранят вне базы (на файловой системе или облачном хранилище типа S3), а в БД кладут только ссылку/путь. Впрочем, небольшие файлики или документы иногда хранят и внутри, но осторожно.

Примеры реляционных СУБД:

• MySQL (https://www.mysql.com) – одна из самых популярных открытых СУБД, особенно в веб-приложениях.
• PostgreSQL (https://www.postgresql.org) – мощная открытая СУБД с богатым функционалом (называют "Swiss Army knife", поддерживает расширения, GIS, JSON и т.д.).
• Oracle Database – коммерческий гигант, известный своей производительностью и богатыми возможностями для enterprise (и высокой ценой).
• Microsoft SQL Server – основной продукт от Microsoft для хранения данных, широко используется в корпоративных приложениях на Windows/.NET.
• SQLite (https://sqlite.org) – легковесная встраиваемая база, которая хранит всё в одном файле. Идеальна для мобильных приложений, небольших сайтов или прототипов.

(И это далеко не все: есть ещё DB2, MariaDB, Firebird... но перечислить абсолютно все продукты невозможно – их десятки.)

Документные базы данных (NoSQL Document-Oriented)

Представьте, что вам не хочется дробить данные по куче таблиц. Вместо этого вы хотите хранить целый объект целиком, в виде документа – например, JSON. Вот для этого и придуманы документные БД. В них каждая запись – это документ (обычно в формате JSON, реже XML или BSON). Документы хранятся в коллекциях (аналог таблицы), но жёсткой схемы нет: каждый документ может иметь свой набор полей. Один документ про пользователя может содержать поля name, age, другой – name, age, hobbies, favoriteColor и ничего, система не возразит. Такая гибкость облегчает эволюцию данных: можно добавлять новые поля "на лету", не трогая старые записи.

Документные базы идеально подходят, когда данные по структуре могут меняться или разнородны. Например, профили пользователей с кучей настроек, статьи с произвольными метаданными, товары с разными атрибутами. JSON-структуры позволяют вложенность: вы можете в одном документе хранить целое дерево. Например, документ "заказ" может содержать внутри массив товаров, а те – вложенные документы с деталями. Никаких JOIN – вся связанная информация вместе! Это упрощает жизнь разработчикам: прочитал один документ – получил сразу всё, что нужно по объекту.

Конечно, гибкость схемы – палка о двух концах. Бизнес-логика приложения должна следить, чтобы важные поля не вдруг отсутствовали, и т.д. Но для многих задач (CMS, быстрый прототип) document-oriented БД дают скорость разработки.

Как запрашивать данные? Документные БД обычно позволяют делать запросы по полям внутри документов (почти как SQL WHERE field=value). Например, можно запросить все документы пользователей, у которых age > 30 AND city = "Moscow". Для этого нужны индексы на полях, иначе поиск превратится во full scan (пробег по всем документам). Большинство документных СУБД умеют создавать индексы на атрибуты или даже вложенные поля. Однако есть нюанс: некоторые облачные документные БД требуют индекс обязательно. Например, Google Firebase Firestore не позволит выполнить запрос с фильтрацией по полю или сочетанию полей, если нет соответствующего индекса – вместо результата вы получите ошибку и предложение создать индекс. Такая строгость обусловлена производительностью: Firestore масштабируется горизонтально, и полный скан коллекции был бы слишком дорог. Поэтому "нет индекса – нет запроса", все запросы всегда быстрые. В MongoDB или CouchDB более либерально: можно запросить без индекса, но это будет медленно (база просто переберёт все документы). Но мы-то с вами грамотные – знаем, что важные поля нужно индексировать, верно?))

Для чего подходят документные БД? Для любых данных в формате JSON или похожем, особенно когда структура записей может меняться или сильно различаться. Отличный выбор для контент-ориентированных систем: блоги, каталоги товаров, профили, логи событий. Хранение деревьев – пожалуйста: можно вложить дочерние элементы внутрь родительского документа (правда, если дерево очень большое, документ разрастётся). Хранение файлов – документные БД позволяют сохранять бинарные данные, часто есть поддержка "вложений". Например, CouchDB поддерживает attachments: файл прикрепляется к документу, как вложение к письму, и база его хранит. MongoDB реализует GridFS – разбивает большой файл на кусочки и сохраняет как набор документов. Но здесь тоже действует правило разумности: хранить профили пользователей с аватарками (картинки) – норм, а вот видео по 500 МБ пихать в документную БД не стоит. Проще положить видео на отдельное файловое хранилище, а ссылку хранить в документе.

Примеры документных БД:

• MongoDB (https://www.mongodb.com) – самая известная документная база. Хранит JSON-подобные документы (BSON), поддерживает сложные запросы по полям, агрегатные операции, гео-запросы и пр. Распределяется, масштабируется, поддерживает даже мульти-документные транзакции (в новых версиях).
• Apache CouchDB (https://couchdb.apache.org) – хранит документы в JSON, славится репликацией и офлайн-режимом. Отлично подходит, когда нужно синхронизировать данные между устройствами (например, мобильное приложение и сервер): CouchDB может работать на устройстве локально и потом "сливаться" с сервером, когда появится связь.
• Firebase Firestore (https://firebase.google.com) – облачная документная БД от Google/Firebase. Очень удобна для мобильных и веб-приложений: обеспечивает репликацию в реальном времени (данные обновляются на всех клиентах мгновенно) и офлайн-кэш. Но, как упомянуто выше, требует продумать индексы для всех сложных запросов.
• Amazon DynamoDB – распределенная NoSQL база от AWS. По сути гибрид ключ-значение и документной: каждая запись имеет ключ и набор атрибутов (могут быть вложенные JSON). Очень масштабируемая (авторы хвастались, что DynamoDB выдерживает пиковые нагрузки распродаж на Amazon.com). Интересный факт: прообраз DynamoDB – система Dynamo, которую Amazon разработала еще в 2000-х для хранения сессий и корзин покупательских, когда реляционные базы не тянули масштаб. Эта работа вдохновила многие NoSQL, в честь Dynamo назван даже стиль консенсуса. Сейчас DynamoDB – это полностью управляемый сервис, где не нужно думать про сервера, но надо думать про ключи и индексы, чтобы эффективно запрашивать данные.
• Couchbase (https://www.couchbase.com) – сродни CouchDB+Memcached в одном флаконе: очень быстрая база, сочетающая документы и механизм кеширования. Умеет SQL-подобный язык N1QL для запросов по JSON-документам и даже поддерживает транзакции.

(Другие: IBM Cloudant – облачная на основе CouchDB, Amazon DocumentDB – совместима с MongoDB, ArangoDB – объединяет документный и графовый подход, о нём чуть позже.)

Базы данных ключ-значение (Key-Value Store)

Это самый простой и быстрый тип хранилища: ассоциативный массив на стероидах. Данные хранятся как пара ключ -> значение. Ключ уникален, по нему и происходит доступ – мгновенно (обычно через хэш-таблицу). Значение – что угодно: строка, JSON, двоичный BLOB. База не знает структуру значения, она просто отдает его по ключу.

Где это полезно? Когда нужно хранить и быстро получать кусочки данных по известному идентификатору. Классический пример – кэширование. Допустим, у вас веб-сайт и нужно быстро отдавать результаты тяжелых запросов: вы можете кэшировать HTML страницы в key-value хранилище, где ключ – URL, значение – готовый HTML. При следующем запросе сайта вы сразу вернёте кэш, минуя генерацию страницы. Другой пример – сессии пользователей: каждому пользователю присвоен уникальный ключ (например, токен или session_id), и в KV-хранилище лежит структура сессии (залогинен ли, последние действия и т.п.). Обращение по ключу – за доли миллисекунды, намного быстрее, чем лазить в основную базу.

Key-Value базы очень быстрые и масштабируемые, именно благодаря своей простоте. Многие работают в оперативной памяти, чтобы достигнуть максимальной скорости. Но они почти не умеют сложных запросов: никаких фильтров по значению, никаких объединений – только get/set по ключу. То есть поиск по значению невозможен, если вы сами не организуете для этого отдельный индекс. Значение хранится непрозрачно для системы. Если вам надо "найти всех пользователей старше 30", а данные лежат в key-value, придётся доставать все записи и фильтровать на стороне приложения – это очень медленно и нелепо. Поэтому KV-хранилища используют, когда заранее известно, по какому ключу вы будете получать данные, и нет потребности делать сложные выборки.

Особенности: Некоторые key-value движки предлагают не только плоский key->blob, но и элементарные структуры данных: например, Redis помимо строковых значений умеет списки, хэши, множества и даже отсортированные множества. Это расширяет диапазон задач: например, можно хранить счетчики, списки сообщений и т.п., обращаясь все так же по ключу. Но по-прежнему нет "запросов" с условиями внутри значений.

Индексы: По сути, сам ключ – уже индекс. Других индексов обычно нет (кроме тех же Redis-структур, где можно по составному ключу искать). Если нужно поддерживать поиск по нескольким атрибутам, key-value не справится – идите в документную или реляционную. В некоторых системах, кстати, обязателен первичный ключ для доступа: например, Apache Cassandra (хоть она и не совсем простое KV, но близка) – все запросы должны содержать ключ раздела, иначе ничего не выйдет. Это похоже на наш пример с Firestore: в распределённых KV/колонновых базах архитектура заставляет вас думать о ключах заранее.

Для чего подходят KV-хранилища? Для кэша, сессий, настроек, токенов авторизации, временных данных, простых счетчиков и прочих случаев, когда вам нужны очень быстрые чтение/запись по ключу и не нужны сложные запросы. Многие используют их как дополнительный слой над основной базой, чтобы разгрузить последнюю. JSON можно хранить как значение (например, ключ – ID пользователя, значение – JSON с профилем). Но тогда вы не сможете прямо в KV базе спросить "а дай-ка всех, у кого age>30" – придётся выгружать всех и фильтровать вручную, что нереально при большом объеме. Деревья напрямую не представляются, но можно, например, использовать иерархические ключи. Некоторые KV поддерживают ключи как путь с разделителем (например, user:1001:preferences), что похоже на файловую систему или дерево. Скажем, etcd (распределённый KV от CoreOS) хранит конфигурацию Kubernetes – по сути, ключи представляют древовидную структуру настроек (/cluster/nodes/node1/...). Но запросы всё равно по конкретному ключу или префиксу. Файлы можно сохранять, если они небольшие: ключ – имя файла или id, значение – содержимое. Так работает, например, объектное хранилище Amazon S3 – по сути, гигантская распределённая key-value база, где ключ – путь/имя объекта, а значение – файл. Но S3 заточено именно под большие файлы и потоковую отдачу, а типичные KV базы (типа Redis) – под быстрые мелкие чтения/записи.

Примеры key-value хранилищ:

• Redis (https://redis.io) – супербыстрый хранилище в памяти, поддерживает различные типы значений (строки, списки, хеши и т.д.). Часто используется как кеш, брокер сообщений (Pub/Sub) и просто "швейцарский нож" для ускорения приложений. Данные можно сбрасывать на диск для персистентности, но основное – оперативка.
• Memcached – тоже in-memory кеш, очень простой: только строки по ключу, без изысков. Зато крайне быстрый и минималистичный. Часто веб-серверы держат Memcached для кэширования результатов запросов к базе.
• etcd (https://etcd.io) – распределённый key-value с консенсусом (Raft) под капотом. Гарантирует согласованность и используется для хранения конфигураций, метаданных, где важно, чтобы несколько экземпляров видели одни и те же данные. Как уже сказано, Kubernetes хранит состояние кластера в etcd. Так что, можно сказать, ваш Kubernetes кластер работает благодаря крошечной key-value базе!
• LevelDB/RocksDB – это библиотеки-хранилища, встраиваемые в приложения, от Google и Facebook соответственно. Они предоставляют persistend key-value хранилище (записи хранятся на диске, оптимизированы под SSD). Часто используются внутри других систем (например, внутри Chrome для IndexedDB, или внутри Apache Kafka для состояния стримов). Разработчики могут использовать их напрямую, если нужен свой легковесный движок хранения.
• Amazon DynamoDB – снова его упомянем здесь, так как исторически он родился как key-value store (каждый item имеет ключ и атрибуты). Позже функциональность расширили до документной (JSON-структуры в атрибутах). В целом, DynamoDB можно отнести и к KV, и к документным.

(Другие: Memcached, Hazelcast, Ignite, Voldemort (разработан LinkedIn), и даже кононический Berkeley DB из 90-х – все они в категории key-value.)

Колонно-ориентированные базы данных для аналитики (Columnar Databases)

Переходим к более свежим штукам. Колонно-ориентированные базы данных хранят данные не построчно, как реляционные, а постолбцово. То есть берут столбец (атрибут) и сохраняют значения этого столбца подряд. Например, есть таблица с колонками (дата, пользователь, клик). Обычная база хранит строки: (2025-07-10, user123, кликнул), (2025-07-11, user456, кликнул) ... А колонно-ориентированная сохранит отдельно все даты подряд, всех пользователей подряд, все действия подряд. Зачем так? Чтобы ускорить аналитические запросы. Представьте, вы хотите посчитать средний возраст пользователей или сумму продаж по годам. В SQL базе нужно читать каждую строку и выбирать нужный столбец. А в колоннарной – сразу берётся весь блок нужного столбца, который часто ещё и сжат. Получается меньше чтения с диска и лучше использование CPU cache. Итог: на агрегации по колонкам производительность в разы выше.

Колонковые базы часто используются для хранилищ данных (Data Warehouse), отчетности, анализа больших объёмов (OLAP). Они хорошо справляются, когда запрос охватывает очень много строк, но относительно немного столбцов. Например, "подсчитать суммарные продажи по категориям за год" – можно прочитать только столбцы "категория" и "сумма", проигнорировав тонны других деталей каждой транзакции. В классической row-базе читался бы каждый ряд целиком, тратя ресурсы на ненужные поля.

Примечание: колонно-ориентированные системы обычно тоже используют какую-то форму SQL для запросов, потому что аналитикам SQL привычен. Но под капотом у них нет классических B-Tree индексов по отдельным значениям – в этом и нет большого смысла, когда ты сканируешь миллионы строк за раз. Вместо этого могут применяться сжатие, инверсные индексы для текста, хэш-индексы для точного поиска или индексы-сигналы (как в ClickHouse, где можно задать primary key для сортировки, и он поможет пропускать ненужные блоки данных).

Особенности и ограничения: Такие системы обычно менее приспособлены для транзакционной нагрузки (OLTP). Вставлять по одной строчке не так эффективно – им лучше когда данные пачками залетают. Часто они применяются в режиме "append-only" (только добавление, редко обновление/удаление). Некоторые колоннарные СУБД не обеспечивают полной транзакционной целостности на уровне отдельных записей (хотя, например, ClickHouse уже поддерживает Atomic database engine, а Vertica или Snowflake обеспечивают атомарность загрузки). В общем, их стихия – быстро прочитать большой объем и посчитать что-то.

Для каких задач колонно-ориентированные БД? Для аналитики, отчетности, BI, хранения больших исторических данных, которые нужно регулярно обрабатывать запросами. Например, аналитика веб-логов: количество посетителей в час, пути кликов, распределение чего-либо по категориям. JSON и сложные структуры – обычно нет, схема должна быть более-менее табличной (хотя некоторые позволяют вложенные поля, например, BigQuery поддерживает вложенные повторяющиеся поля). Деревья – не по адресу, здесь все плоско. Файлы – тоже нет, только если вы храните пути к файлам для аналитики, а не содержимое.

Зато в своей области (аналитика) колоннарные базы творят чудеса: известны кейсы, когда запросы на миллиардах строк выполняются за секунды. Одно из самых громких имён – ClickHouse, разработанный в «Яндексе» для сервиса аналитики (Яндекс.Метрика). Он настолько быстр, что при правильной настройке способен обрабатывать миллиарды записей в секунду на одном сервере (правда, в очень оптимизированных сценариях). Неудивительно, что ClickHouse покорил мир аналитики данных, особенно в обработке логов, мониторинга, событий.

Примеры колонно-ориентированных аналитических БД:

• ClickHouse (https://clickhouse.com) – открытая система от Yandex, сейчас развивается отдельной компанией. Поддерживает SQL, масштабируется по кластеру, очень быстро обрабатывает аналитические запросы. Отлично подходит для логов, метрик, BI. Интересный факт: название происходит от слов Click (клик пользователя) и House (хранилище) – т.е. "дом для кликов", отражая исходную задачу хранения веб-аналитики.
• Google BigQuery – облачный сервис от Google. Вам даже не видны сервера, просто загружаете данные и пишете SQL-запросы. Под капотом – колонно-хранилище с распределением по датацентрам. BigQuery славится тем, что может за секунды обработать терабайты данных (если кошелек позволяет 😅, плата за отсканированные гигабайты).
• Amazon Redshift – еще один облачный data warehouse, от AWS. Тоже использует колонковое хранение, предназначен для BI-отчетности, интегрируется с инструментами аналитики вроде Tableau, QuickSight.
• Snowflake – облачная Data Warehouse платформа, ставшая чрезвычайно популярной в последнее время. Интересна архитектурой отделения хранения от вычислений и тем, что полностью управляется (никаких настроек кластеров, просто загружай данные и спрашивай). Snowflake хранит данные колонно и прозрачно масштабируется под запросы. Компания Snowflake взлетела до многомиллиардной оценки, что показывает, насколько востребованы аналитические СУБД.
• Apache Druid – открытая система для реального времени и OLAP. Она гибридно хранит свежие данные в памяти, старые на диске (колонно-ориентированно), оптимизирована под time-series analytics. Например, ее используют для аналитики потоков событий, когда нужен как интерактивный анализ последних часов, так и по историческим данным.
• Vertica – колоннарная СУБД, созданная в 2000-х (сейчас принадлежит Micro Focus). Очень быстрая на аналитических запросах, в свое время опередила даже Hadoop по скорости на некоторых задачах.

(Другие: MonetDB, Greenplum (MPP архитектура), Sybase IQ – тоже пионеры колонкового подхода, плюс в классических СУБД появились опции хранения колуннами, например, MS SQL Server имеет Columnstore Index для ускорения OLAP-запросов.)

Ширококолонные NoSQL базы данных (Wide-Column Stores)

Название похоже на предыдущий тип, но не путайте: ширококолонные базы – это детище NoSQL-революции, и они отличаются от аналитических колоннарных систем. Иногда их еще называют семейство столбцов (column family) или таблицы типа Bigtable.

Суть: данные организованы в строках, но каждая строка может иметь свой собственный набор столбцов, отличающийся от других. Столбцы объединяются в семейства (семейство столбцов – это группа, похожая на "таблицу"). У каждой строки есть ключ (primary key, часто разделён на partition key и clustering key). По этому ключу данные распределяются по узлам кластера. А вот количество и название столбцов в каждой строке могут быть разными, и новые столбцы можно добавлять "на лету" для конкретной записи.

Если запутались, представьте электронную таблицу, где в первой строке 3 колонки заполнены, во второй – 5 (два дополнительных), в третьей только 2. В реляционной базе такое невозможно без ALTER TABLE. А в wide-column – нормально. Это чем-то похоже на документные БД, но вместо JSON мы явно храним "колонки" с именами и значениями. Такой формат вышел из внутренней системы Google Bigtable – статьи про нее навели Facebook, Apache и других на мысль сделать подобное как open-source.

Особенности: Ширококолонные базы распределенные и масштабируемые, часто работают на десятках серверов. Они оптимизированы под большие объемы и высокую скорость записи. Многие из них предлагают в итоге согласованность (eventual consistency): т.е. при записи данные реплицируются на несколько узлов асинхронно, и может быть момент, когда разные узлы видят разные данные, но со временем всё синхронизируется. (Обычно можно настроить уровень консистентности – чтение может требовать подтверждения с нескольких реплик, если нужно). Это сделано ради производительности и отказоустойчивости.

Запросы: Обычно весьма ограничены. Обязательное требование – знание ключа. Вы должны в запросе указать хотя бы primary key (партицию). Например, в Apache Cassandra запросы без указания ключа раздела не поддерживаются (можно включить ALLOW FILTERING, но тогда каждый узел кластера станет перебирать свои данные, что на практике не работает на больших объемах). Идеология: вы продумываете схему под запросы. Под каждый тип запросов – своя "таблица" с ключами, по которым будете искать. Это противоположность реляционного подхода "вот нормализованная модель, а запросы какие угодно через JOIN". Здесь – "денормализуй данные, дублируй, но каждое хранилище отвечает своему запросу". Зато, зная ключ, чтение очень быстрое (порядок O(1) или O(log n) в пределах партиции).

Индексы: Некоторыe wide-column базы поддерживают вторичные индексы, но с оговорками. В Cassandra, например, вторичные индексы есть, но не рекомендуются для масштабных данных, так как не сильно помогают (все равно ищут по всем узлам). Поэтому обычно, если нужен новый критерий поиска, просто создают новую колонновую семейство с другим ключом, дублируя данные (denormalization is a norm).

Для чего подходят wide-column базы? Для случаев, когда у вас очень много данных и четкие запросы по ключам. Например, телеметрия IoT: миллионы датчиков шлют показания. Вы кладете их по ключу {device_id, timestamp}. Потом легко запросить по устройству за диапазон времени. Или система мониторинга – ключ это имя метрики, а столбцы – метки и значения по интервалам. Также социальные сети: можно хранить для каждого пользователя список друзей или постов, ключ – user_id, а дальше колонки как атрибуты постов или ID друзей. Многие такие базы используются именно для таймсерии или журналов (логов), что пересекается с темой time-series БД ниже, но wide-column более общего назначения. Если документные базы похожи на JSON, то wide-column – больше похоже на двухмерный key-value: ключ1 (строка) + ключ2 (имя колонки) -> значение.

JSON и вложенные данные: Обычно нет, структура плоская, но вы можете в качестве значения хранить JSON или serialized blob. Однако тогда вы теряете возможность эффективно фильтровать по содержимому, так что зачем тогда брали такую базу? Проще сразу документную. Деревья: Можно моделировать, например, ключом сделать путь (типа parent/child), но явной поддержки и удобства нет. Файлы: Не лучшая идея, хотя теоретически можно нарезать файл на блоки и хранить по ключам, но это уже изобретение велосипеда.

Примеры ширококолонных БД:

• Apache Cassandra (https://cassandra.apache.org) – один из самых известных проектов NoSQL. Распределён без единой точки отказа, заимствовал идеи из Dynamo (ключи и репликация) и Bigtable (колонные семейства). Использует CQL (Cassandra Query Language), синтаксис напоминающий SQL, но со своими ограничениями. Cassandra способна работать на сотнях узлов, обеспечивая очень высокую доступность. Интересный факт: Cassandra изначально разработали в Facebook для поисков по переписке пользователей, а в open-source передали Apache. Сейчас ее юзают Netflix, Instagram и многие другие для различных больших распределённых хранилищ.
• Apache HBase – еще одна реализация идей Bigtable, но поверх Hadoop HDFS. Хорошо интегрируется с Hadoop экосистемой (MapReduce, Spark). Используется там, где уже есть кластер Hadoop и нужны быстрые случайные чтения/записи (чего нет у MapReduce). HBase активно применяли в Yahoo, Twitter для сообщений, в Salesforce, и т.д.
• ScyllaDB (https://www.scylladb.com) – попытка сделать "Cassandra на стероидах". Это реализация протокола Cassandra на языке C++ с асинхронной архитектурой, выжимающей максимум из современного железа (особенно NVMe и многопоточности). Совместим с Cassandra по API, но показывает лучшую производительность и предсказуемые задержки.
• Google Bigtable – мы не можем им лично воспользоваться вне Google Cloud (там он доступен как сервис Cloud Bigtable), но упомянуть стоит, ведь это дедушка всех этих систем. Именно по статье о Bigtable (2006 г.) мир узнал, как Google хранит триллионы строк веб-индекса. Bigtable хранит данные в виде строковых ключей и колоночных семейств, с версионированием по времени. Если вы используете GCP и вам нужна Cassandra-подобная штука без администрирования, можно подключиться к Cloud Bigtable.
• Azure Cosmos DB (Table API) – в облаке Azure Cosmos есть разные модели (ему даже отдельный раздел ниже посвятим). Один из них – Table API, совместимый с API Azure Table Storage и похожий на ключ-значение или wide-column хранилище для простых структурированных записей. Это менее известная часть Cosmos по сравнению с MongoAPI или GremlinAPI, но упомянуть можно.

(Другие: Accumulate (на основе Bigtable идей + безопасность, от NSA), Couchbase можно отнести отчасти – у него подход к хранения комбинирует и документы, и ключ-значение со средствами масштабирования. Но главные представители wide-column – Cassandra и HBase.)

Графовые базы данных

Если данные — это сеть связей, графовая база будет кстати. Графовые СУБД хранят информацию в виде графа: узлы (вершины) и связи между ними (ребра). Классический пример – социальная сеть: узлы это люди, ребра – "дружат", "подписаны", "лайкнули пост" и т.д. Другой пример – города (узлы) и дороги (ребра), или преступники и звонки между ними (для аналитики связей). В реляционных базах представлять такое приходится через таблицу связей (много-много JOIN, сложные рекурсивные запросы). Графовые БД же специально заточены под обход графа: быстро найти все связи, даже на нескольких уровнях.

Как это выглядит внутри? Каждый узел может иметь свойства (имя, возраст для человека, например). Каждое ребро тоже может иметь свойства (например, ребро "дружат с 2015 года" – свойство дата начала дружбы). Главное – можно задавать запросы типа "найти всех друзей друзей пользователя X" или "найти кратчайшую цепочку связей между A и B". Такие запросы графовая БД выполнит эффективно, потому что хранит соседей узла прямо вместе с ним, а не раскиданными по разным таблицам. Обычно есть специальные языки запросов: Cypher (у Neo4j), Gremlin, GQL (графовый SQL в разработке).

Для чего графовые БД? Для социальных графов, рекомендаций (например, граф "пользователь – смотрел фильм – фильм", можно искать "пользователи, похожие на вас по вкусу, смотрели еще и вот это"), fraud detection – выявление аномальных связей (граф транзакций, где подозрительно если много связей через одни и те же узлы). Еще одно направление – семантические сети и знание: графовые базы могут хранить онтологии, связи типа "Кошка – это животное", "Автор – написал -> Книгу". Для таких задач часто используют подвид графовых баз – трёххранилища (triplestore) для RDF-данных и SPARQL-запросов. Но не будем слишком углубляться: суть в том, что графовые БД блестяще работают там, где данные имеют сложные, разнообразные связи.

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

Деревья: А дерево – это частный случай графа (без циклов). Так что графовая БД – идеальная для хранения и навигации по древовидным структурам. Например, оргструктура компании: "директор -> начальник отдела -> сотрудник" – легко хранить как граф и запросить "покажи всю подчиненную иерархию директора". В SQL для этого понадобятся рекурсивные CTE или хранимки; в документной – можно вложить уровень, но многоуровневое дерево целиком не вложишь или сложно обновлять. Граф же просто хранит отношения parent-child, и обход по ним тривиален.

JSON: Связанный вопрос – а JSON с вложенностью? Документная база хранит иерархию атрибутов внутри документа, но это не совсем то, что произвольный граф между записями. JSON хорош для вложенных объектов, но если элементы имеют связи с другими – JSON не поможет. Например, пост в блоге можно хранить как документ с комментариями внутри. Но если комментарии имеют ответы (древовидно) – вложенность растет и становится громоздкой. Если же пользователь может комментировать несколько постов – это уже связь между сущностями "Post" и "User". Граф здесь может явно показать: User -> (комментирует) -> Post. В общем, графовые БД дополняют документные в тех случаях, когда важны отношения между отдельными записями.

Файлы: Как правило, нет. Графовые БД – про метаданные и связи. Хранить большие блобы (файлы) в них смысла нет, лучше хранить ссылку на файл как свойство узла, если уж надо.

Примеры графовых БД:

• Neo4j (https://neo4j.com) – самая известная графовая база. Существует с mid-2000s, очень зрелая. Поддерживает язык Cypher, который понятный и декларативный (например, MATCH (u:User)-[:FRIENDS_WITH]->(f:User) RETURN f – найдет друзей пользователя). Neo4j изначально файловая и нефедеративная (т.е. работает на одном сервере или кластере реплик для отказоустойчивости, но не шардинг), хотя сейчас есть продукт AuraDS, умеющий распределение. Применяется в тысячах проектов от социальных приложений до маршрутизации (да, можно искать пути на графе дорог).
• Amazon Neptune – облачная графовая СУБД от AWS. Поддерживает сразу два популярных интерфейса: Gremlin (императивный язык запросов из проекта Apache TinkerPop) и SPARQL (для RDF триплетов). То есть Neptune может хранить как property graph (похожий на Neo4j), так и семантические сети. Он управляемый – AWS берёт на себя масштабирование (но в пределах одного кластера), бэкапы и пр. Neptune хорош, если вы в AWS и не хотите поднимать свой графовый сервер.
• JanusGraph (https://janusgraph.org) – распределенный граф, открытый и масштабируемый. Он не хранит данные сам, а использует в качестве хранилища одну из ширококолонных или ключ-значение баз: поддерживаются Cassandra, HBase, Scylla, BerkeleyDB, etc. Иными словами, JanusGraph разбивает граф на множество узлов по разным серверам, пользуясь возможностями бекенда для хранения. Запросы выполняются через Gremlin (TinkerPop stack). Благодаря этому JanusGraph умеет граф с миллиардами вершин/ребер на сотне серверов, но настройка и оптимизация такого зверя – непростое дело. Используется, например, в финтехе для анти-мошенничества, в анализе соц. графов и др.
• ArangoDB (https://arangodb.com) – многомодельная база (документы + графы + ключ-значение). В контексте графов интересна тем, что позволяет комбинировать подходы – например, хранить документы (узлы) и их связи в одном движке и запросами AQL (Arango Query Language) вытаскивать и связи, и документы. Штука мощная, но менее популярна, чем Neo4j.
• Azure Cosmos DB (Gremlin API) – в Microsoft Azure, Cosmos поддерживает режим графового хранилища с использованием API Gremlin (соответствует Apache TinkerPop). Это позволяет, аналогично Neptune, получить облачный управляемый граф.

(Другие: OrientDB – была графо-документная БД, сейчас кажется заброшена; FlockDB – граф от Twitter (очень упрощенный), сейчас редко используется; также есть специализированные triple-store: Apache Jena, Virtuoso, Stardog – для семантических графов RDF.)

Базы данных временных рядов (Time Series)

Time-series DB – это базы, оптимизированные для данных, снабженных отметкой времени. Представьте поток показаний: температура датчика каждую секунду, курс акций каждую миллисекунду, метрика загрузки CPU каждые 5 секунд. Такие данные идут непрерывно и растут очень быстро. Временной ряд – это упорядоченный по времени набор точек (timestamp + значения). Можно, конечно, хранить их в обычной SQL таблице, но со временем эта таблица разрастётся до неповоротливых размеров, а запросы типа "средняя температура за последний час по всем датчикам" будут буксовать.

Time-series СУБД придуманы, чтобы эффективно писать и читать по времени. Обычно они хранят данные в таблицах/сериях, разбитых на интервалы времени (например, по дням, по часам). Внутри оптимизируют хранение: значения за близкие по времени метки могут храниться как массив или сжиматься алгоритмами, учитывающими последовательность (типа Gorilla-компрессия от Facebook, если интересно). Также часто поддерживаются агрегации, downsampling: можно запросить не сырые данные, а, скажем, сгруппированные по минутам (и база сама посчитает среднее/максимум).

Ещё одна фишка – Retention Policy: данные "стареют" и их автоматически можно удалять или агрегировать. Например, детальные секунды хранятся месяц, а старше – только средние значения по минуте, и т.д. Это помогает удерживать объемы под контролем.

Индексы: Временные ряды почти всегда хранятся с основным индексом по времени (в конце концов, это главное измерение). Дополнительно, как правило, есть теги/метки – например, для сенсоров это ID устройства, локация и т.п. Они индексируются, чтобы можно было быстро выбрать ряд по условию "device_id = X AND time between ...". По сути, внутри это похоже на комбинацию: ключ (устройство) + время, что напоминает wide-column подход, но с доп. удобствами именно под время.

Для чего подходят TSDB? Для мониторинга, метрик, IoT, финансовых данных, аналитики событий со штампом времени. Примеры:

• Система мониторинга серверов (типа Prometheus, Graphite): CPU, память, сетевой трафик записываются каждую N секунд.
• Хранилище финансовых тиков: каждое изменение цены актива с точным временем.
• Сенсоры умного дома/промышленности: показатели температуры, давления и т.д. с периодической отправкой.

Почему не использовать просто SQL/NoSQL? Можно, но TSDB дает лучше производительность на диапазонах времени и удобные функции (агрегировать по интервалам, хранить деривативы, percentiles). Кроме того, интерфейс часто дружит с графиками: те же Prometheus/Influx имеют интеграцию с Grafana или своими визулами – сразу графики строить.

Деревья и JSON: Не про это – данные плоские (метки+значения+время). Файлы: тоже нет, разве что если интерпретировать "временной ряд" как поток логов, но логи лучше хранить в ELK или ClickHouse.

Примеры TSDB:

• InfluxDB (https://www.influxdata.com) – известная открытая TSDB. Свой формат хранения, свой SQL-подобный язык InfluxQL (в новых версиях заменяется на Flux – функциональный язык для сложной аналитики). Оптимизирована под запись миллионов точек в секунду. Широко используется для DevOps-метрик, IoT.
• TimescaleDB (https://www.timescale.com) – необычный зверь: это надстройка (extension) над PostgreSQL, превращающая его в time-series базу. Она автоматически разбивает большую таблицу на часты (chunks) по времени (например, по месяцу) и умеет прозрачно управлять ими. Timescale дает удобство SQL (работаешь как с обычной табличкой с временем), но в фоне – оптимизация как у TSDB. Поддерживает continuous aggregates (материализованные представления по промежуткам). Хороша тем, что можно использовать всю экосистему Postgres (типы данных, джоины с другими таблицами).
• Prometheus (https://prometheus.io) – система мониторинга, но её ядро – как раз встроенная TSDB (хранит метрики). Prometheus сам собирает метрики, складывает у себя (файл на диск, сжатие – все дела). Он не предназначен как "универсальная" база, у него нет внешнего API широкого, но в контексте метрик DevOps его часто упоминают. Если вам нужно именно хранить и визуализировать метрики – Prometheus может быть достаточно.
• OpenTSDB – one of early distributed TSDBs, построена над HBase (wide-column). То есть хранит точки как строки HBase, а предоставляет интерфейс для запросов по времени. Сейчас менее популярен, потому что появились более удобные штуки, но исторически был важен.
• VictoriaMetrics – относительно новая TSDB, написанная на C++/Go, совместимая с Prometheus (может выступать как его долговременное хранилище). Отличается высокой эффективностью хранения и тем, что хорошо работает как в одной бинарнике, так и в кластере.

(Другие: Graphite – старый добрый, больше как сервис рендеринга графиков + хранение в RRD-файлах или Whisper-формате; Facebook Gorilla (внутренний); Heroic (от Spotify, на Cassandra) и множество решений от облачных провайдеров, часто на основе уже названных.)

Векторные базы данных (Vector databases)

Наконец, самый свежий тренд последних лет – векторные базы, появившиеся благодаря буму машинного обучения и AI. Что это такое? Представьте, у вас есть нейросеть, которая преобразует, скажем, текст или изображение в набор чисел – вектор (embedding). Эти векторы – многомерные точки (например, 512-мерный вектор). И похожие по смыслу тексты будут расположены близко друг к другу в этом пространстве. Задача: хранить миллионы таких векторов и быстро находить ближайшие к заданному (nearest neighbors). Зачем? Семантический поиск. Например, у вас база документов, у каждого есть embedding по смыслу. Пользователь задает вопрос, вы делаете embedding вопроса и ищете близкие векторы документов – таким образом находите релевантные ответы по смыслу, а не по словам. Это лежит в основе поиска с искусственным интеллектом, рекомендаций ("похожие товары/фильмы") и т.п.

Можно, конечно, хранить векторы в обычной БД, но сравнение десятков/сотен измерений – дорого, индексов обычных не сделаешь. Тут и приходят на помощь векторные БД: они используют специальные структуры данных (аннотированные деревья, графы близости, hashing техники) для approximate nearest neighbors (ANN). То есть не точный поиск, как в SQL, а "похоже на…". Зато очень быстро даже на огромных массивах.

Особенности: Векторные базы обычно позволяют добавлять векторы, прикреплять к ним метаданные (например, ID документа, категорию – чтобы потом фильтровать "найди похожие, но из категории X"). Запрос: подай вектор, получи N самых близких (сосчитано косинусное расстояние или евклидово). Важно, что многие такие СУБД ориентированы на интеграцию с ML-пайплайнами и часто предоставляют облачный сервис. Они могут поддерживать обновление в реальном времени, а могут требовать перестроения индекса (в зависимости от реализации). По уровню зрелости они еще догоняют традиционные базы, но активно развиваются.

Для чего подходят: Для всех AI-приложений, где нужно искать по сходству, а не точному совпадению. Чат-боты на базе LLM – хранят эмбединги знаний, чтобы по вопросу быстро вытаскивать нужный контекст. Поиск изображений по образцу – храним эмбединги картинок, на вход подаем картинку и ищем похожие. Музыка, рекомендации, да даже в кибербезопасности – сравнение поведенческих профилей (тоже вектора).

Внутри: Много математики – алгоритмы типа HNSW (small-world graphs) или IVF (inverted file). Но это детали. Главное: векторные базы – это совершенно новый класс, дополняющий традиционные. Они не заменят ни реляционные, ни документы, потому что хранят специфичные данные (векторы) и отвечают на специфичные запросы (nearest neighbors).

Примеры векторных БД:

• Pinecone (https://www.pinecone.io) – один из первых managed-сервисов для векторных данных. Разработчики могут заливать свои эмбединги и искать по ним, Pinecone решает вопросы инфраструктуры, масштабирования. Очень популярен в AI-сообществе благодаря простоте API.
• Milvus (https://milvus.io) – открытая платформа, вышедшая из проекта Zilliz. Позволяет поднять свой сервер для хранения векторов, поддерживает распределённость, различные алгоритмы индексации. Можно интегрировать с Python, и прочими языками для ML-проектов.
• Weaviate (https://weaviate.io) – еще одна открытая векторная СУБД, с богатыми возможностями: она, например, может сама вызывать модель для генерации векторов (имеет модули для текста, изображений), поддерживает графовые связи между объектами, GraphQL для запросов. Очень интересный проект, идет к мульти-модальности.
• FAISS – не совсем база, а библиотека от Facebook (Meta) для поиска по векторным индексам. Многие векторные БД внутри используют алгоритмы FAISS. Его можно применять и напрямую, если нужен простой офлайн поиск (но он не предоставляет ни хранения на диске, ни сервера – просто алгоритмы).
• ElasticSearch / OpenSearch – хотя это поисковые движки, упомянем: они добавили возможность векторного поиска (dense_vector тип и kNN queries). То есть в существующий движок, больше заточенный под текст, прикрутили и хранение/поиск по эмбедингам. Это удобно, если у вас уже есть Elastic для текстового поиска, то можно и семантический сделать, не вводя новую систему. Но специализированные решения (как выше) обычно дают лучше производительность на больших объемах.
• PostgreSQL + pgvector – аналогично, можно и в Postgres класть векторы (тип VECTOR через расширение pgvector) и делать запросы ближайших соседей. Это работает (особенно на малых наборах), но не так быстро на миллионах записей, как специализированные движки, и требуются костыли для приближенного поиска. Так что, для эксперимента сойдет, для продакшна серьезного – лучше что-то вроде Pinecone или Milvus.

(Векторные БД – очень молодая область. Помимо названных, есть также Qdrant, Vespa (Yahoo/Oath проект), Annoy (Spotify lib), ScaNN (от Google) и др. Едва ли нужно их все знать, но имейте в виду, что направление горячее.)

Многомодельные базы данных (multi-model)

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

• Azure Cosmos DB – облачная база, которая через единый сервис предлагает разные API: документо-ориентированный (совместим с MongoDB), ключ-значение (Table API), графовый (Gremlin), и даже поддерживает SQL-подобный язык для JSON. Все это на одном движке с распределением по датацентрам и автомасштабом. То есть Cosmos может одновременно заменить MongoDB, Cassandra и Neo4j (в определенной степени). Удобно для разработчиков на Azure: не думаешь о разных системах, используешь нужный API, а данные хранятся в одной кластерной инфраструктуре.
• ArangoDB – уже упоминали, объединяет документную модель, графы и key-value. Вам не нужно заводить отдельную Neo4j и Mongo – Arango позволяет хранить и документы, и устанавливать ребра между ними. У него свой язык AQL, который универсален для запросов разных типов (можно в одном запросе и по атрибутам фильтровать, и по графовым связям ходить).
• Couchbase – тоже комбинирует документное хранилище с key-value (по сути, это Memcached + JSON). Плюс у Couchbase есть индексы, поддержка SQL++ (расширение SQL для JSON), и даже полный текст поиск и аналитику прикрутили. Такой швейцарский нож для тех, кто хочет все из одной коробки.
• Oracle и другие РСУБД – тоже тянут в эту сторону: Oracle, MS SQL, PostgreSQL – все добавили JSON, графовые расширения (у Oracle и MS есть возможность делать графовые запросы в SQL), полнотекстовый поиск, и т.д. В итоге одна реляционная база выполняет роль и документной, и поискового движка, и частично графового (в Postgres, к примеру, есть pgRouting для графов, PostGIS для геоданных, JSONB для документов – по сути, multi-model платформа выходит).

Multi-model базы – компромисс: они могут не быть лучшими в каждой категории, но достаточно хороши, чтобы не тащить зоопарк систем. В небольших или средних по нагрузке проектах это оправданно: проще поддержка. Однако под огромные масштабы специализированные решения всё ещё чаще выигрывают (specialized > general). Поэтому у гигантов вроде Google/Amazon всё равно куча разных баз для разных сервисов (никто все на одну не посадит, слишком рискованно и неудобно).

Заключение

Фух, мы рассмотрели столько видов баз, что можно закружиться! Давайте пробежимся кратко через аналогии, чтобы уложилось в голове:

• Реляционные (SQL) – строгие учителя: требуют правильной структуры, зато гарантируют порядок и успеваемость (данные консистентны). Хороши для важных вещей (деньги, учет), чуть менее гибки для неожиданностей.
• Документные – свободные художники: "хочешь добавить новое поле – пожалуйста!" Прекрасны, когда нужна свобода формата и быстрые итерации, особенно с JSON. Но за свободу иногда платишь несогласованностью данных (надо самой логикой следить) и отсутствием join-ов (приходится жить без сложных реляций или вручную их решать).
• Key-Value – спринтеры: побеждают в коротких забегах (очень быстрый доступ по ключу), но не умеют выполнять фигурное катание (сложные запросы). Берите их для ускорения и кеша, но не пытайтесь научить делать аналитические трюки.
• Колонно-ориентированные (аналитические) – это такие складские работники с узкой специализацией: они медленно крутят гайки (транзакции), зато если попросить "посчитай всё на складе по категориям" – мгновенно выдают отчёт, потому что у них всё разложено по полочкам-колонкам.
• Wide-Column (ширококолонные) – архитекторы под запрос: строят хранилище точно под заранее известные запросы. Очень масштабные, но очень требовательные к проектированию. Если знаешь, что тебе всегда нужны данные по ключу X за период Y – они твой выбор. Если начинаешь спрашивать "а покажи-ка по другому полю" – они разведут руками.
• Графовые – социальные сети в мире баз: они заботятся об отношениях между данными. Если данные плотно связаны, графовая БД позволит раскрыть всю эту паутину за считанные шаги. Но не зови её считать среднее по зарплатам – это она тоже может, конечно, но без энтузиазма.
• Time-Series – хронометристы: все по порядку, по времени. Отлично знают, что произошло в 10:00, а что в 10:05, и быстро скажут, сколько всего набежало за час. Их конек – непрерывные потоки показателей.
• Векторные – новаторы: понимают "смысл" данных, пусть и скрытый в виде списка чисел. Они как библиотеки для нейросетей – хранят знания AI. Если надо искать не точное совпадение, а "что-то похожее", им равных нет. Но сами по себе они не хранят привычные нам строчки или документы, только математическое представление.
• Многомодельные – швейцарские ножи: стараются понемногу уметь всё. Это удобно, но не всегда так остро наточено, как отдельный инструмент. Зато, возможно, за ними будущее, где разработчикам не нужно думать о десятке технологий – достаточно одной гибкой базы.

В реальности, конечно, часто используют в комбинации. Например, типичный современный проект: PostgreSQL для основных данных (пользователи, транзакции), Redis для кэша и сессий, ElasticSearch для полнотекстового поиска по логам или контенту, ClickHouse для аналитики событий, Neo4j для специфичного графового анализа (если вдруг нужен, скажем, социальный граф или рекомендательная система), а теперь еще и какой-нибудь Milvus для AI-поиска. Зоопарк? Да, но каждый зверь при деле.

Главное – правильно выбрать инструмент под задачу. Нет универсально лучшей базы данных, есть подходящая для конкретной задачи. Если вы хакатоните быстрый прототип с гибкими объектами – вероятно, начнёте с документной MongoDB. Если строите систему платежей – выберете проверенный PostgreSQL или Oracle. Если нужна скорость в мелочах – добавите Redis. И так далее.

Надеюсь, этот обзор помог разобраться, что к чему в мире баз данных. Теперь, когда вам встретятся термины вроде "колонновая база" или "графовая СУБД", вы не будете пугаться, а скажете: "А, знаю, где это пригодится!". Базы данных – увлекательная тема, и она продолжает развиваться. Кто знает, может через пару лет появятся новые виды (например, уже говорят о квантовых базах данных или еще что-нибудь сумасшедшее). Но это история для будущего. А пока успехов в выборе правильной базы для ваших данных!