Time-series и поисковые хранилища

Time-series: другая форма записи

Через десять минут ты поймёшь, почему обе фичи из вступления были дорогими, какое свойство хранения каждая нарушала — и как выглядит правильное решение, когда те же требования появятся снова.

Time-series данные — поток измерений с метками времени, только на добавление: метрики серверов, показания IoT-сенсоров, события приложения, биржевые тики. Их форма необычна: записи многократно превосходят чтения, почти ничто никогда не обновляется и не удаляется поштучно, а запросы почти всегда — «агрегируй эту метрику по этому окну времени». Time-series база (Prometheus, InfluxDB, TimescaleDB, AWS Timestream) построена вокруг этой формы, и три свойства её определяют:

• Хранение, оптимизированное под запись (LSM-деревья). Вместо обновления данных на месте (что значит случайный seek диска на запись — медленно) log-structured merge tree буферизует записи в памяти и сбрасывает их на диск как отсортированные неизменяемые файлы, сливая их в фоне. В результате записи — последовательные append, единственное, что и шпиндельные, и твердотельные диски делают быстрее всего, поэтому LSM-хранилище впитывает куда большую пропускную способность записи, чем традиционное обновление на месте (B-дерево). Обмен — больше работы при чтении и во время фоновой компакции, и это нормально, потому что time-series тяжело на запись.
• Даунсэмплинг. Тебе не нужно посекундное разрешение для данных за прошлый год — оно нужно за последний час. Даунсэмплинг предагрегирует старые данные в более грубые корзины (посекундно → поминутно → почасово), сжимая их на порядки, сохраняя тренд.
• Retention (срок хранения). Старые сырые данные автоматически отбрасываются после окна (держи 7 дней сырыми, 90 дней по 1 минуте, 2 года по 1 часу). Retention — первоклассная декларативная функция: хранилище само удаляет устаревшие данные, так что хранение остаётся ограниченным вместо вечного роста.

Вместе эти три свойства означают, что time-series хранилище принимает данные на полной скорости, пока объём остаётся ограниченным и запросы по любому окну времени работают быстро — без малейшего давления на транзакционный primary. Без retention таблица растёт бесконечно; без даунсэмплинга старые данные в посекундном разрешении жрут место и тормозят диапазонные запросы; без LSM-записи диск становится узким местом ещё до того, как данные успели лечь.

Реляционный primary может хранить метрики, но это не та форма: B-tree индексы деградируют, когда миллиарды строк churn-ятся, нет встроенного даунсэмплинга или retention, а пожарный шланг записи конкурирует с транзакционным трафиком за тот же буфер-кеш и WAL — ровно то отравление, что ты видел с блобами в 02-blob-and-object.

Поиск: почему LIKE — это не поиск

Поисковая строка, что находит документы по любому слову, выглядит как запрос к базе, но это принципиально другой паттерн доступа. SQL-ный WHERE description LIKE '%word%' вынуждает полный скан: ведущий wildcard означает, что никакой B-tree индекс не поможет, так что движок читает и подстрочно сравнивает каждую строку. Он также не даёт ранжирования по релевантности, нет стемминга («running» матчит «run»), нет терпимости к опечаткам, нет многополевого скоринга. Работает на тысяче строк и рушится на миллионе.

Поисковый движок (Elasticsearch/OpenSearch, Lucene, собственный полнотекст Postgres через tsvector) решает это, строя инвертированный индекс. Где обычный индекс отображает строка → значения, инвертированный — наоборот: для каждого термина (слова) он хранит список документов, которые его содержат. Так «найди документы, содержащие payment и failed» становится двумя дешёвыми lookup-ами списков, пересечёнными — без скана. Поверх инвертированного индекса движок наслаивает то, чего LIKE никогда не сможет: токенизацию и стемминг (так «payments» находит «payment»), скоринг релевантности (какой документ — лучший матч, а не просто какой-то), нечёткий матч под опечатки и агрегации (фасеты/фильтры). Поэтому ты тянешься к поисковому движку в момент, когда «поиск» значит больше, чем «точный префиксный матч по одной колонке».

Senior-решение: специализировать или перегрузить primary?

Каждое специализированное хранилище — реальная цена: ещё одна система запускать, мониторить, бэкапить, защищать и (трудная часть) держать в синхроне. Так что вопрос никогда не «лучше ли time-series база на метриках?» (очевидно да), а «мой primary правда не тянет эту нагрузку, и стоит ли провал второй системы?» Честная прогрессия:

1. Начни на primary. У Postgres удивительно способный полнотекстовый поиск (tsvector) и time-series расширения (TimescaleDB). Для умеренного масштаба одно хранилище куда дешевле головной боли согласованности двух.
2. Специализируй, когда бьёт измеренный предел — пожарный шланг метрик вытесняет транзакционный трафик, или LIKE-поиски сканируют миллионы строк и отваливаются по таймауту. Предел, а не модное слово, оправдывает второе хранилище.
3. Считай специализированное хранилище производным индексом, а не источником истины. Реляционный primary остаётся системой записи (source of truth); поисковый движок и time-series хранилище — оптимизированные под чтение проекции его. Это ключевая рамка: если поисковый индекс потерян, ты пересобираешь его из primary — ты не теряешь данные, лишь доступность этого пути запроса.

Проблема двойной записи

В момент, когда запись должна лечь в два хранилища — строка в Postgres и документ в Elasticsearch — у тебя проблема двойной записи (dual-write), и она сложнее, чем кажется. Наивный код пишет в оба последовательно: db.save(order); search.index(order). Но это две системы без общей транзакции. Если процесс падает между двумя вызовами, или запись в поиск провалилась, а запись в БД прошла, хранилища расходятся — заказ существует, но не ищется, тихо, навсегда. Слепой ретрай может задвоить запись; обернуть их в «транзакцию» невозможно через две системы (распределённой транзакции тут нет). Надёжные паттерны делают primary единственным источником истины и выводят второе хранилище из его журнала записи:

• Change Data Capture (CDC) — хвостуй журнал репликации базы (её WAL/binlog) и стримь каждое закоммиченное изменение в поисковое/time-series хранилище. Коммит БД — единственное атомарное событие; обновление индекса — нижестоящий потребитель, который может ретраить и переигрывать.
• Transactional outbox (транзакционный исходящий ящик) — в той же транзакции БД, что пишет заказ, пиши ещё и событие «проиндексируй этот заказ» в таблицу outbox; отдельный релей читает outbox и толкает в поисковый движок. Поскольку строка заказа и строка outbox коммитятся атомарно, событие нельзя потерять.

Оба разделяют один принцип: никогда не доверяй двум независимым записям остаться согласованными — сделай одно хранилище авторитетным и распространяй из его коммита. Принять, что производное хранилище в итоге согласовано (новый заказ ищется через секунду), обычно нормально; притворяться, что двойная запись атомарна, — баг.