Хранение и запросы истории транзакций для сотен миллионов аккаунтов

Question

IT Interview Practice · Accepted Answer

**Партиционируйте ledger по аккаунту и времени, держите свежие данные горячими, а старые холодными, и относитесь к строкам как к append-only неизменяемому ledger — чтобы история одного аккаунта была малым индексированным срезом, а не сканом миллиардов строк.** Паттерн доступа всегда «один аккаунт, диапазон дат», поэтому партиционируйте под него.

## Архитектура

```text
Write ─▶ Ledger table (append-only, immutable)
          partition by (account_hash, month)
              │
     ┌────────┴─────────┐
  HOT tier            COLD tier
  last 3 mo           older
  Postgres/SSD        S3/Parquet, Glacier
     │                    │
  index-seek        keyset paginate ──▶ API (account+range)
```

## Как это работает

- **Партиционирование по аккаунту + времени.** Хешируйте id аккаунта в N бакетов, затем range-партиционируйте по месяцу. Запрос по одному аккаунту/месяцу попадает ровно в одну партицию — БД отсекает остальные. Это ограничивает каждое чтение независимо от общего размера.
- **Неизменяемый ledger.** Никогда не делайте `UPDATE` транзакции; коррекции — это новые сторнирующие строки. Это даёт audit trail, безопасную репликацию и позволяет агрессивно кэшировать (строки никогда не меняются).
- **Hot/cold tiering.** Держите последние ~3 месяца на быстром SSD/Postgres для низколатентных чтений; перекатывайте старые партиции в **S3/Parquet** (запрос через Athena/Trino) или Glacier. 95% запросов попадают в свежие данные, поэтому большая часть хранилища может быть дешёвой.
- **Keyset-пагинация.** Листайте через `WHERE (ts, id) < (:last_ts, :last_id) ORDER BY ts DESC LIMIT 50` — а не `OFFSET`. Offset сканирует и отбрасывает пропущенные строки; keyset seek-ает по индексу напрямую, O(1) на страницу.

## Взгляд с точки зрения интервью

Интервьюер прощупывает **выбор ключа партиционирования** и **пагинацию**. Хорошие ответы говорят «партиционировать по аккаунту»; отличные объясняют, **почему keyset побеждает OFFSET** на глубоких страницах, почему **ledger неизменяем** (аудируемость, отсутствие конкуренции блокировок) и как **tiering** режет стоимость. Ловушка — единственная гигантская таблица с составным индексом: она работает, пока индекс не перестанет помещаться в RAM, и каждое чтение становится disk-bound.

## Компромиссы и сбои

- **Ключ партиционирования трудно поменять.** Выбирайте аккаунт+время заранее; ре-партиционирование сотен миллионов строк позже — это проект миграции.
- **Кросс-аккаунтные запросы страдают.** «Общий объём по всем аккаунтам» теперь разлетается по партициям — выносите такое в OLAP-rollup.
- **Холодные чтения медленны.** Достать выписку трёхлетней давности из Glacier занимает минуты; задайте ожидания пользователю или прогревайте по запросу.
- **Горячие партиции.** Аккаунт-«кит» или текущий месяц могут быть hotspot; суб-партиционируйте или кэшируйте.
- **Когда не нужно:** миллионы строк (а не сотни миллионов) помещаются в одну индексированную таблицу Postgres — не стройте tiering, который вам не понадобится. Тянитесь к этому на масштабе, где индекс единственной таблицы перестаёт помещаться в память.

Архитектура

Как это работает

Взгляд с точки зрения интервью

Компромиссы и сбои

Похожие вопросы