Почему идеи в базах данных возвращаются. Часть I

Гость представляется: в Т-Банке он работает семь лет, пришёл на классические реляционные решения на Oracle, а до этого лет пять-семь работал на американский рынок; сейчас его команда отвечает за платформенные и неплатформенные базы данных — поддержку, развитие платформы и закрытие пользовательских сценариев внутри своей инфраструктуры. Александр объясняет выбор собеседника: часть движков компания раздаёт как сервис, а направление добавляет в платформу новые опции вроде векторных баз, чтобы их не разворачивала каждая команда. Статья прошлогодняя: 17 страниц, из них 13 основного текста и четыре — ссылок; такие обзоры Александр любит за «вертолётный» взгляд и тренды. Текст продолжает серию, начатую двадцать лет назад работой «What Goes Around Comes Around» — по словам Александра, 2005 года, — и её соавтором тоже был Майкл Стоунбрейкер, серийный создатель баз данных: Ingres, потом PostgreSQL, потом наработки, превратившиеся в Vertica.

Второй автор, Эндрю Павло, — исследователь из Карнеги — Меллона, известный идеями про автономные базы, забирающие на себя часть работы DBA; лет пять назад он приезжал на HighLoad, но на выступление Александр не попал и смотрел в записи: тогда в автономность верилось слабо, а сейчас тенденции ведут туда. Алексею в статье не хватило географии: PostgreSQL внутри страны развивается не так, как в комьюнити, и это меняет ландшафт; Александр соглашается, что авторам интереснее американский и глобальный корпоративный рынок. Реляционной модели в перечне нет: она стандарт де-факто и мера сравнения для всех остальных. Алексей видит здесь ловушку — сравнение подтягивает всё обратно к реляционке, — хотя признаёт, что бизнес по сути табличный. Первая статья, напоминает Александр, предсказывала, что реляционные базы расширят функциональность, а конкуренты не отожмут значимую долю рынка.

Разбор идёт по кубикам статьи, и первый — MapReduce: подход популяризовал Google, которому нужно было раскидывать обработку по множеству нод и сводить результаты. Следом появился открытый инструмент с теми же идеями — Hadoop, а поверх него базы вроде Hive, возвращавшие привычный SQL. Модель оказалась дорогой: real-time не получить, ресурсов уходит много, и сам Google свои решения в основном прикопал; Алексей добавляет, что технологию успели внедрить во множество бизнес-сущностей, а жить с ней накладно. Авторы записывают её в отмирающее legacy, но Александр объясняет, почему она живёт: если данные в HDFS лежат и всё устраивает по скорости и стоимости, переход не обосновать; собственный Hadoop есть и у компании — уже нецелевой. В ключ-значении, считает Алексей, авторы ограничились быстрым доступом по ключу и парой слов про кэш, а самое интересное для его рынка — внешний роутер при шардировании; Александр разворачивает сценарий: шард остаётся обычной PostgreSQL, а роутер нужен быстрый и отказоустойчивый, лучше in-memory и, наверное, с персистом. Redis, добавляет он, умеет куда больше простого ключ-значения, хотя сейчас у него проблемы с лицензией и форки.

Документные базы, замечает Александр, чаще обсуждают прикладные разработчики: MongoDB избавляла от постоянной трансляции объектов в реляционные структуры и обратно — сериализуй объект в документ и клади в базу. Предложение сработало, хотя гарантий консистентности между коллекциями не было, а в первых версиях настоящего сброса на диск не происходило и данные можно было потерять. Потом на движке осели околоэнтерпрайзные решения, транзакции пришлось добавить, а Mongo стали использовать просто как большую быструю шардированную базу. Алексей смотрит со стороны эксплуатации: JSON выиграл у XML простотой модели, переход из реляционного мира лёгкий, но ACID приходится натягивать, надстройки расширяют ядро, которое под это не проектировали, и Mongo в поддержке инженеры не любят. Дальше собеседники разбирают главную плату — схему: реляционная база проверяет запись на входе и позволяет катать миграции, а при небрежной работе с документами схема уезжает в приложение, и оно копит зоопарк версий одного типа документов — как мобильная разработка тянет старые версии операционок.

Wide-column разбирают на Cassandra, которая есть у компании как сервис: у Google была статья про Big Table, коллеги из Meta захотели похожего. Моделирование здесь инвертировано — идёшь не от нормализации, а от того, как приложение пишет и, главное, читает: выбираешь ключ шардирования, чтобы запрос не разлетался по всем шардам, сортировку под раскладку данных и иногда дублируешь их в разные представления. Кластер принимают на поддержку по процедуре: инженеры валидируют структуру с командой — переход из реляционного мира рождает ошибки проектирования. В плюсах — быстрые вставки и TTL, сам подчищающий записи; отличается и движок хранения: вместо B-дерева журнал, таблицы в памяти и периодически компактящиеся файлы на диске. Полнотекстовый поиск Александр советует начинать с возможностей PostgreSQL, а не разворачивать отдельный движок сразу. У Алексея на этот счёт история: на прошлой работе у клиента перестал обновляться текстовый индекс в Oracle, разбирались месяца четыре с инженерами вендора, и он нашёл шестую, не описанную в документации вьюшку с несинхронизированными строками, — патч приехал месяца через два.

Векторные базы Александр объясняет от простого: сокращать размерность умели и до LLM, а трансформер первым же шагом превращает вход в вектор — например, размерности 768. Записать его нетрудно, сложность в поиске: нужна метрика вроде косинусной близости и приближённый поиск соседей, зато семантика работает — спрашиваешь «король», получаешь «королеву», а связка полнотекстового и векторного поиска даёт инструмент для retrieval-augmented generation. Гипотезу «векторных баз нам нужно много» в компании проверяли инженерно: взяли два плагина к распространённому PostgreSQL — один pgvector, название второго Алексей не вспомнил, — два специализированных движка, а вдогонку, по его памяти, Elasticsearch и Cassandra. Специализированные СУБД выигрывают за счёт модели хранения, но расширения съедобны на небольших объёмах. Про базы данных массивов Александр честно говорит, что знает мало: идея в многомерном значении вместо скалярного, нужном научным данным. С графами он играл в Neo4j и хвалит язык Cypher, где паттерн-матчинг по графу чередуется с табличными выборками; сложность же в эксплуатации — граф трудно разрезать по машинам, а глубину обхода приходится ограничивать отдельно: чем богаче модель, тем труднее заставить её работать. Вторую половину, про системную архитектуру, договариваются записать отдельным выпуском.