[1/2] Monarch: Google's Planet-Scale In-Memory Time Series Database (Рубрика #Architecture)

Наконец-то я дочитал оригинальный whitepaper про эту интересную систему для работы с time-series данными от Google. Идея появилась после моего погружения в архитектурный whitepaper, где эту систему перепроектировали с использованием quality-based подхода и UML диаграмм. Если кратко, то суть примерно такая, что в 2020 году вышла статья на VLDB Endowment про эту самую масштабную в мире базу для временных рядов
1) Monarch - это глобально распределённая, мультитенантная in‑memory БД временных рядов для мониторинга почти всех пользовательских и инфраструктурных сервисов Google. Ежесекундно принимает терабайты метрик и обрабатывает миллионы запросов. Архитектура - разделенная по регионам с глобальным plane запросов и конфигурации.
2) Ключ к масштабу: лексикографическое шардирование по “target”, агрегация на этапе сбора, компактные индексы подсказок (Field Hints Index), двухуровневые исполнители запросов (Root/Zone Mixers).
3) На июль 2019: почти 950 млрд рядов в оперативной памяти (~петабайт сжатых данных); средняя агрегация при сборе 36:1 (до 1 000 000:1); индексы позволяют срезать fan-out до десятков тысяч лишних leaf‑узлов.

Как это примерно работало
- Система мультитенантная и глобальная. Региональные зоны автономно принимают и хранят данные в памяти, а глобальные плоскости обеспечивают единый запрос и конфигурацию. Это снижает зависимость от внешней персистентности и повышает доступность мониторинга во время инцидентов.
- Модель данных и запросов отличается от предшественника Borgman (кстати, именно Borgman стал прототипом Prometheus - об этом можно глянуть в документалке, о которой я рассказывал). В отличие от “строчных ключей” прежних систем, Monarch использует типо‑насыщенную реляционную модель метрик (включая распределения/гистограммы) и выразительный язык запросов, что упрощает статический анализ и оптимизации.
- Архитектура обработки выглядела примерно так
-- Ингест: клиенты → ingestion routers → зона → leaf router → Leaves (in‑memory). Уже здесь может работать collection aggregation.
-- Запросы: Root Mixer распределяет по зонам (Zone Mixers); Index Servers (в т.ч. Field Hints Index) заранее исключают нерелевантные узлы, резко уменьшая фан‑аут.
- Отдельно были сделаны оптимизации
-- Collection aggregation: в среднем 36 входных рядов → 1; в экстремуме до 10⁶:1. Экономит память/CPU и трафик.
-- Field Hints Index (FHI): зоны с >10 000 leaves и триллионами ключей; FHI позволяет отсечь ~73 000 нерелевантных leaves для сложных выборок.
-- Лексикографическое шардирование по target: все метрики одного объекта попадают на один leaf → локальные агрегации/джойны, меньше fanout.

В продолжении рассказ, а что было с этой системой дальше.

#Software #Architecture #DistributedSystems #SRE #Engineering #Databases #Data