SageDB — система для хранения логов и универсальный распределенный поисковый движок для разных источников данных, например, внутреннего хранилища логов, VictoriaMetrics и Elasticsearch. Он позволяет извлекать и анализировать информацию с использованием языка запросов MageQL.

Изначальное назначение SageDB — заменить Elasticsearch в проекте Sage Observability. Как мы к этому пришли и почему разрабатываемое решение более эффективное, чем Elasticsearch, рассказываем в статье.

Команды в Т‑Банке использовали разные инструменты мониторинга: Zabbix, ELK, Graylog, Prometheus и другие. Проблема в том, что эта разрозненная экосистема не обеспечивала возможности для комплексного анализа данных, а настройка оповещений превращалась в настоящую проблему. Кроме того, управление такой сложной системой требовало значительных усилий.

Мы сделали шаг вперед и внедрили единую систему мониторинга, в качестве решения выбрали Splunk — универсальную платформу для обработки машинных данных.В 2019 году Splunk покинул российский рынок, что сделало невозможным продление лицензий и его использование. Альтернатив на рынке не было, риски, связанные с вендорлоком, — высокие, поэтому мы решили разрабатывать собственный инструмент для поиска и анализа логов. Так и появился Sage Observability.

В 2019 году мы выбрали Elasticsearch в качестве хранилища логов и поискового движка. Со временем команда накопила большой объем данных и научилась эксплуатировать Elasticsearch. Мы стали лучше понимать его проблемы и ограничения — и осознали, что могли бы решить их лучшим способом, используя знания о природе наших данных:

• Наши данные — неизменяемые, поэтому значительная часть функциональности Elasticsearch нам не нужна. Из-за неизменяемых данных мы можем применять более агрессивные методы сжатия.
• Индексы имеют довольно высокую стоимость, часто их размер сопоставим с объемом хранимых данных.
• Построение индекса требует значительных ресурсов и существенно замедляет процесс вставки данных.
• После превышения порога в несколько петабайт данных и значительного увеличения числа узлов в кластере Elasticsearch становится довольно хрупким и требует постоянного внимания SRE.
• Есть сложности с горизонтальным масштабированием. По сути, единицей масштабирования становится большой сервер.

Все это органически привело нас сначала к поиску альтернатив, потом к мысли о глубокой кастомизации Elasticsearch, а затем к разработке собственного специализированного решения — SageDB. Более подробную информацию о том, какие альтернативы мы рассматривали и почему они нам не подошли, можно найти в докладе «SageDB: зачем мы пишем свою базу данных».

Наши первоначальные высокоуровневые требования к SageDB — система должна быть проще в операционной поддержке, обеспечивать лучшую масштабируемость и обходиться дешевле в обслуживании.

В процессе развития SageDB прошла несколько этапов: от привычной схемы, напоминающей классическую БД, до текущей архитектуры shared-nothing с разделенным compute и storage. Каждый вычислительный узел поискового движка может стать корневой точкой для запроса: при необходимости он произведет изначальную компиляцию запроса, затем разошлет задачи по дочерним узлам и в конце произведет результирующую агрегацию.

На 2025 года система включает три приложения — Pipe, Reducer и Synapse — и четыре внешние зависимости: Kafka, Postgres, S3 и VictoriaMetrics. Каждое приложение состоит из набора независимых копий (инстансов) и поддерживает линейное масштабирование. В системе выделяются два основных сценария: чтение и обработка данных (ingest) и поиск.

Pipe отвечает за чтение данных из Kafka, формирование сжатых контейнеров и метаданных и их последующую отправку в Postgres и S3. Дополнительно Pipe предоставляет API для выгрузки незавершенных блоков данных, что нужно для поиска информации от групп с низкой интенсивностью записи. При этом нет ограничений на формат входных данных, за исключением зарезервированного поля@timestamp и полей group и dc, которые будут перезаписаны (обогащены).

Reducer выполняет функции поиска, включая обработку входных запросов, извлечение метаданных из Postgres и загрузку блоков данных из S3 для последующего вычисления результатов. Он знает о наличии других кластеров и обладает информацией:

• о «точке входа» для взаимодействия с Reducer’ом в других кластерах;
• обо всех соседних инстансах Reducer’а в пределах одного кластера (полная связность).

У пользователей есть возможность направлять запросы в любой кластер для выполнения поиска.

Reducer оперирует концепцией Provider для поиска данных, включая логи, метрики, трейсы и другие источники информации. В текущей реализации предусмотрены три провайдера: Storage — для логов, VictoriaMetrics — для метрик, Elasticsearch — если нужна интеграция с уже существующими кластерами Elasticsearch. В рамках своих функций Reducer выполняет такие обязанности:

• Разбор поискового выражения, заданного на языке MageQL.
• Компиляция запроса в вычислительный граф.
• Создание вычислительных задач внутри собственных и соседних кластеров.
• Агрегация результатов из собственного и соседних кластеров.

В дополнение к основной функциональности, описанной чуть выше, reducer — еще и распределенный кэш, другими словами — хранит в памяти данные контейнера полностью или частично, например только Bloom-фильтры или временной индекс. Чтобы каждый инстанс хранил только определенный непересекающийся набор контейнеров, используется подход с Rendezvous Hashing.

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

Давайте поговорим о формате хранения данных в SageDB. Может появиться вопрос: почему выбран именно этот формат, а не, к примеру, Apache Parquet? Как он применяется и какие преимущества у него есть?

Наша цель — снизить затраты на декодирование по памяти и использованию процессорных ресурсов. Еще одно важное условие — обеспечение работы с произвольными данными без необходимости заранее определять схему, как это требуется, например, для того же Parquet. После детального анализа множества вариантов, включая FlexBuffers, Apache Arrow и MessagePack, мы приняли решение создать собственный файловый формат, который бы сочетал в себе оба требования.

Работа с документами и записями организована по принципу наложения структур на память, аналогично тому, как это происходит в языке C. Только в нашем случае это делается с использованием direct-буферов Netty на языке Kotlin/Java.

Файл разделен на куски (chunks) по некоторому ключу партиционирования. Это позволяет значительно уменьшить объем данных, которые необходимо извлечь и обработать при поисковом запросе, что, в свою очередь, снижает нагрузку на сеть и CPU. Некоторые запросы, например статистические (min, max, count и другие), могут выполняться без непосредственного обращения к основным записям файла. Для их обработки достаточно использовать лишь индекс и вероятностные структуры данных.

Разработка SageDB началась во второй половине 2021 года. Первый прототип с традиционной схемой compute-storage появился полгода спустя. Затем мы значительно изменили архитектуру приложения и в качестве основного таргета для деплоя выбрали Kubernetes. Прототип SageDB c cloud-native-архитектурой появился в начале 2023 года. В тот момент он уже был полностью совместим по API c пользовательским интерфейсом Sage Observability.

26 апреля 2024 принято считать датой релиза: в этот день первые группы логов были переведены в SageDB. Пионерами в этом процессе стали около 50 групп, или 1% от всех групп логов в компании. Они помогали выявлять первичные проблемы и затем валидировать предложенные решения. Дополнительно мы продолжали дублировать данные в Elasticsearch в качестве резервного хранилища, что при необходимости позволяло в любой момент переключить поиск обратно на Elasticsearch.

Следующая важная веха — кратное увеличение количества перенесенных групп: около 400, или почти 10% от общего количества. В этот период мы обнаружили и решили первые серьезные проблемы с Pipe, который начал проявлять нестабильность под высокой нагрузкой. Оптимизировали работу с Postgres, в частности отказались от использования jsonb для хранения определенной части метаинформации и заменили его на бинарные блоки. Эти блоки создаются с использованием тех же механизмов, что и для записи основных данных.

На начало 2025 года мы перевели в SageDB около 1 400 групп, что составляет 30% от всех групп, представленных в Т-Банке на этот год. Ситуация выглядит достаточно стабильной, и мы достигли такой степени уверенности, что рассматриваем возможность полного отключения зеркалирования данных для этих групп в Elasticsearch.

Мы проанализировали возможности и преимущества SageDB и сформулировали плюсы от использования:

• Простое горизонтальное масштабирование системы, потому что мы можем с легкостью добавлять узлы в любой момент.
• Ориентация на развертывание в Kubernetes, а это тренд в Т-Банке.
• Сжатие данных в SageDB более эффективно, чем в Elasticsearch. Согласно измерениям, проведенным в начале 2025 года, коэффициент сжатия варьируется от 10 до 20 в зависимости от типа данных. Если представить, что весь текущий объем логов компании был бы переведен на SageDB, то он, что важно, измерялся бы в терабайтах, а не в петабайтах.

Главный вызов — работа с группами логов большого размера, превышающими 20—30 МБ/с. Мы полагаем, что могут возникнуть сложности с пропускной способностью сети, и это, возможно, потребует дальнейшего развития архитектуры и внедрения механизмов для работы с локальными volume. Но это не пугает нас — наоборот, пробуждает интерес к нашей работе и предстоящим достижениям.