Привет, Хабр! Я Роман Севрук, менеджер по развитию решений СУБД в К2Тех. Мы своего рода детективы на технологическом рынке — выслеживаем и разбираем каждое новое решение в сегменте российских баз данных.

В этой статье рассмотрим новую подборку баз данных с разными технологическими подходами, которые формируют ландшафт локальной экосистемы российских СУБД. Объясним:

• чем сильна PostgreSQL;

• почему Yandex Database (YDB) подходит для сложных распределенных систем;

• как Tarantool оптимизирована под скорость и работу в real-time.

А чтобы картина была максимально полной — смотрите наш предыдущий обзор по другим российским СУБД. 

Готовы разобраться, кто из них подходит под ваши задачи? Погнали!

Контекст

Раньше с базами данных было проще: можно было решить практически любые задачи. Oracle закрывал потребность в монолитах и безопасности, которая важна, например в банковской сфере. MS SQL Server доминировал в корпоративных информационных системах, веб-приложениях на .NET и системах бизнес-аналитики.

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

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

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

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

PostgreSQL: народная СУБД и ее возможности

Итак, PostgreSQL получила активное развитие, поддержанное большим сообществом специалистов. В России ее активно дорабатывают: появились форки вроде Postgres Pro, Tantor, Arenadata Prosperity, Pangolin, Jatoba.

Причем разработчики не просто затачивают свои решения под потребности конкретной отрасли. Например, Tantor накапливает экспертизу по работе с 1С, а Postgres Pro интегрируется с банковскими АБС, обрастая специальными расширениями.

Вендоры проверяют код на безопасность и совместимость, оперативно реагируют на запросы заказчиков и вносят доработки. Так появились многие дополнительные фичи и мониторинги, которые мы разбирали в прошлой статье. Раньше каждую базу PostgreSQL приходилось проверять через отдельную консоль. Сейчас есть централизованные системы, которые идут в комплекте с СУБД и отслеживают нагрузку сразу по множеству баз.

За что так любят PostgreSQL? 

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

• Если нужно быстро развернуть новую СУБД — PostgreSQL часто лучший выбор и хороший способ набраться опыта перед миграцией важных систем.

• PostgreSQL можно использовать везде, от стартапа до корпорации. Эта СУБД подстраивается под любые задачи и легко кастомизируется. Тысячи расширений позволяют кастомизировать ее под самые разные задачи.

• Большинство вендоров ПО считают поддержку PostgreSQL правилом хорошего тона. На рынке есть готовые решения и патчи для большинства популярных продуктов.

Пределы возможного

Без PostgreSQL российский ИT-рынок оказался бы в куда более сложной ситуации, но, к счастью, можно экспериментировать и оптимизировать эту СУБД под свои нужды. 

И все же у PostgreSQL есть и свои недостатки. Просто перенести данные из Oracle в Postgres не получится — это почти всегда требует серьезной перестройки архитектуры приложения. Вся логика, завязанная на специфические функции Oracle, а их там немало, отправляется на переделку.

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

СУБД Яндекса (YDB) для высоких нагрузок 

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

Магия неограниченного горизонтального масштабирования

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

В кластере СУБД Яндекса нет бутылочного горлышка центрального сервера. Все узлы равноправны и могут обрабатывать запросы (active-active). Кластер состоит из трёх типов узлов:

• Storage nodes (статические) — управляют хранением данных на дисках

• Database nodes (динамические) — обрабатывают SQL-запросы и выполняют транзакции

• Hybrid nodes — комбинируют обе роли для dev-окружений

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

На более глубоком уровне масштабируемость обеспечивается динамическим секционированием (шардингом) таблиц — СУБД Яндекса разбивает таблицы на большое количество секций, которые можно независимо перемещать между узлами кластера и обрабатывать параллельно. 

Шардирование происходит по диапазонам (ranges) первичного ключа. Когда секция превышает пороговые значения по объему данных или нагрузке, система автоматически разделяет ее на две или более части. При снижении нагрузки или уменьшении объема данных секции могут автоматически объединяться обратно, чтобы не тратить ресурсы впустую. 

YDB реализует распределённые ACID-транзакции, используя модифицированный алгоритм Calvin — подход, который обеспечивает строгую консистентность без традиционного двухфазного коммита (2PC). В отличие от оригинального Calvin, YDB поддерживает интерактивные и недетерминистические транзакции через механизм record locking.

СУБД самостоятельно балансирует данные и нагрузку: следит за метриками узлов (CPU, память, сеть) и при необходимости перемещает тяжелые фрагменты с перегруженных машин на менее загруженные.

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

Мультитенантность

Внутри одного кластера СУБД Яндекса можно разместить сотни изолированных друг от друга баз данных. Каждая получает свой собственный выделенный пул вычислительных ресурсов, но при этом все они используют общее хранилище. Иными словами, один кластер способен заменить собой множество разрозненных инстансов СУБД. Администраторы могут гибко управлять ресурсами: выделять или ограничивать долю CPU, памяти и I/O для каждой базы, устанавливая квоты подобно ограничению процессов в Linux (cgroups). Это гарантирует, что высокие нагрузки у одного из арендаторов не повлияют на работу соседей по кластеру, и повышает общую эффективность использования оборудования. Преимущество такого подхода и в том, что все базы данных администрируются централизованно. 

Когда смотреть в сторону СУБД Яндекса?

Если PostgreSQL хорошо работает в сценариях, где достаточно масштабирования в пределах одного сервера, то СУБД Яндекса раскрывает потенциал в высоконагруженных и географически распределенных системах:

• Финансовые расчетные центры, платежные ядра, биллинг, которые должны работать непрерывно.

• Высоконагруженные OLTP-сервисы — крупные банки, e-commerce, ритейл с сотнями тысяч пользователей.

• Промышленность и IoT, где тысячи датчиков непрерывно генерируют данные.

Раньше такие задачи решали дорогими инсталляциями Oracle с привлечением профессиональных команд. Теперь их все чаще решают с помощью СУБД Яндекса.

На ней работают расчетные центры ряда крупных банков, и практически все масштабные сервисы самого Яндекса от платежного сервиса Яндекс.Пэй, платформы такси Яндекс Go, до самого поисковика.

«Мы остановились на YDB, так как эта система позволяет работать с очень большим количеством транзакций…. Проект по модернизации расчетного центра Газпромбанка стартовал в середине 2023 года. Сейчас система уже обрабатывает до 3 млн транзакций в час», — Иван Варжавин, исполнительный вице-президент Газпромбанка для РБК. 

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

Однако стоит помнить, что сравнительно молодая технология означает меньше готовых решений и более скромное сообщество разработчиков по сравнению с PostgreSQL. СУБД Яндекса, хоть и разрабатывается с 2010-х годов, только недавно стала открытой и экосистема вокруг нее еще формируется. На сегодняшний день у этой базы данных меньше специализированных инструментов, плагинов и экспертов на рынке, чем у десятилетиями обкатанного PostgreSQL. Это накладывает определенные риски: при внедрении придётся больше опираться на собственные силы или поддержку интегратора, а поиск ответов на нетривиальные вопросы может занять больше времени.

Яндекс позиционирует свою базу скорее, как долгосрочную инвестицию — экосистему на будущее, где СУБД — это не только транзакции, но и аналитика, брокер сообщений, ИИ. 

Уже сейчас СУБД Яндекса поддерживает гибридные нагрузки: помимо ACID-транзакционности (OLTP) в ней есть колоночные таблицы для OLAP-аналитики, встроенный механизм топиков (очередей сообщений) с поддержкой протокола Kafka и гарантией доставки exactly-once, а также средства для векторного поиска (семантического сравнения данных для ML-задач).

Tarantool для скоростной обработки данных

Tarantool — In-Memory-платформа для задач со счетом на миллисекунды. Она не посягает на задачи классических реляционных систем и работает как отдельный скоростной слой для транзакций и real-time аналитики. Это решение скорее для дополнения классической СУБД, а не прямой замены. Такой подход позволяет вписать Tarantool буквально между бизнес-логикой и основной базой, когда часто изменяемые и требующие молниеносного доступа данные держатся в оперативке, а все остальное — в обычном хранилище.

Вся архитектура Tarantool построена вокруг хранения и обработки данных в ОЗУ. Результат — сотни тысяч транзакций в секунду даже под промышленной нагрузкой. Пользователь всегда видит самые актуальные данные, а сервисы выдерживают пиковые нагрузки вроде массовых авторизаций, моментальных расчетов лояльности или всплесков во время акций.

Tarantool изначально задумывался как решение enterprise-уровня с акцентом на надежность, консистентность, катастрофоустойчивость и горизонтальную масштабируемость, чего часто не хватает классическим in-memory решениям вроде доминирующего на российском рынке Redis.

Посмотрим на главные отличия Tarantool от Redis:

• Гарантии сохранности данных. Redis чаще применяется как неконсистентное решение для ускорения работы, не рассчитанное на строгий ACID-контроль. Tarantool при синхронной репликации может обеспечивать сценарии RPO=0 и использоваться там, где требуется четкая согласованность и высокая доступность.

• Масштабируемость. Redis хорош для небольших кэшей, Tarantool работает с терабайтами данных в памяти (например, в ВТБ один из кластеров хранит порядка 10 терабайт). 

• Управляемость. Для больших объемов данных Redis требует построения сложных кластеров с множеством инстансов и сложной эксплуатацией. Tarantool предлагает более простой и лаконичный подход к администрированию и масштабированию за счет встроенных инструментов и архитектуры. 

• Enterprise-функции: ACID-транзакции, SQL-интерфейс, резервное копирование без downtime в Tarantool.

В общем, Tarantool — полноценное хранилище для бизнес-критичных данных, которое работает очень быстро и отлично показывает себя в задачах, где нужен мгновенный отклик. К примеру, тот же PostgreSQL в подобных условиях пришлось бы сильно оптимизировать (кэшировать, дробить на инстансы), а Tarantool работает «из коробки» с минимальными задержками.

• Банковские системы (клиентские профили и системы авторизации). В Альфа-Банке проект для инвестиционного блока работает на Tarantool уже более 5 лет как единое хранилище — никаких дублей в других базах. Это бизнес-критическая система, где Tarantool является единственным «источником правды». А ВТБ, X5, Beeline и Мегафон используют его для обработки массовых авторизаций.

Результаты объединения данных из разным систем в инвест-бизнесе Альфа-Банка с помощью Tarantool. Источник

• Ритейл и e-commerce (витрины данных и системы лояльности). Миллионы товарных позиций и акций Tarantool обрабатывает в режиме реального времени. Когда пользователь заходит на маркетплейс, каталог должен отображаться мгновенно. Плюс начисления бонусов, обработка чеков, учет акций с моментальной реакцией на поведение клиента.

• Телеком (биллинг, каталоги продуктов и подписок). Это массовая обработка событий, расчеты по миллионам счетов. В биллинговых системах ВТБ Tarantool оперирует десятками терабайт в оперативной памяти. А Мегафон, Билайн, Ростелеком используют Tarantool для работы с продуктовыми каталогами и текущими подписками.

• Real-time аналитика и антифрод. Антифрод-системы должны принимать решения за 100-200 миллисекунд. Нужно не только проанализировать текущую транзакцию, но и сопоставить ее с историческими данными, обновить профили рисков. Для таких сценариев сделали Tarantool Column Store — колоночное хранилище на базе Tarantool для смешанных транзакционно-аналитических нагрузок (HTAP). Это позволяет работать с потоком транзакций и одновременно делать сложные аналитические запросы по историческим данным.

И конечно же, импортозамещение. Tarantool входит в реестр отечественного ПО и сертифицирован ФСТЭК, что критично для банков и госсектора. Для упрощения миграции с Redis создали Tarantool DB-Redis — решение, которое обеспечивает нативный переход. Redis убирается, ставится Tarantool и приложения продолжают функционировать без доработок. 

Разумеется, Tarantool подходит не всем и не всегда:

• Если информация редко запрашивается, держать ее в RAM неоправданно дорого.

• Сложные аналитические запросы. Для JOIN-ов и тяжелой аналитики лучше ClickHouse или PostgreSQL.

• Очень маленькие проекты. Настройка кластера Tarantool может быть избыточна для стартапов.

Как выбрать: сводная таблица 

Собрали все вместе, чтобы сориентировать, как выбирать СУБД из изученных в этом материале под конкретные задачи и какие факторы учитывать:

По опыту внедрений, лучшие результаты получаются при интеграции разных СУБД в рамках единой архитектуры. Real-time данные — в Tarantool, долговременное хранение — в PostgreSQL или Yandex.Database.

Ключевые тренды и прогноз на ближайшие 2-3 года

В ближайшие годы ситуация будет меняться быстро. Будущее за гетерогенными ландшафтами, где под каждую задачу берут подходящий инструмент: YDB для ядра и монолитных high-load, Tarantool для работы с «горячими» данными и real-time витрин, PostgreSQL и его форки для микросервисов, вспомогательных сервисов и менее критичных частей инфраструктуры.

Архитекторы уже проектируют не просто миграцию БД, а пересматривают всю инфраструктуру под новый ИТ-цикл, учитывая быстрорастущие объемы, разнообразие бизнес-процессов и требования к масштабируемости.

PostgreSQL ждет серьезная трансформация в сторону user-friendly. Российские вендоры активно работают над упрощением администрирования и развертывания, чтобы сделать PostgreSQL таким же простым в управлении, как когда-то был MS SQL Server. Кластеризация, нормальное резервное копирование и шардирование уже уводят PostgreSQL от имиджа однобазовой системы и позволяют браться за средние и крупные проекты. Основной вектор — снижение порога входа, чтобы даже без команды DBA можно было внедрять и сопровождать PostgreSQL в enterprise-ландшафтах.

Yandex.Database превращается в эталонную платформу для «тяжелых» инсталляций, где нагрузка, объемы и требования отказоустойчивости уже не под силу ни одному форку PostgreSQL. И все же для ключевых игроков очевиден тренд на универсальность: YDB и Tarantool развивают функционал, позволяющий одной платформе одновременно держать транзакционные и аналитические нагрузки (HTAP): 

• В YDB появляется полнофункциональный аналитический блок, есть планы по развитию гибридного поиска и векторных запросов для поддержки ИИ-запросов и ассистентов.

• Tarantool уже получил свой колоночный движок, развивается CDC-интеграция для потоковой обработки данных и векторный поиск для новых сценариев.

HTAP означает, что одна система — «источник правды» и для реального времени, и для аналитики. Для бизнеса это минимизация интеграционных проблем плюс будущее, в котором можно строить гибкие и быстрые сервисы.

В целом текущая ситуация создает уникальные возможности. Это не кризис, а шанс пересмотреть устаревшие бизнес-процессы и реализовать проекты по модернизации ИT-инфраструктуры, которые раньше постоянно откладывались. Чувствуется азарт: п��оизводители готовы к пилотам, коллаборациям и даже разработке патчей под конкретного заказчика. Главное — перестать искать один молоток на все гвозди и начать строить современную и устойчивую архитектуру.

Что это значит на практике:

• Для архитекторов — время думать экосистемами, а не отдельными продуктами. Проектировать не замену Oracle, а архитектуру на 10 лет вперед.

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

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

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

А как вы решаете вопрос с выбором баз данных? Уже мигрировали на новые решения или пока присматриваетесь? Делитесь своим опытом в комментариях — интересно узнать, с какими вызовами вы столкнулись.