Przechowywanie i odpytywanie historii transakcji dla setek milionów kont

Question

IT Interview Practice · Accepted Answer

**Partycjonuj księgę (ledger) po koncie i czasie, trzymaj świeże dane na gorąco, a stare na zimno, i traktuj wiersze jako niezmienną księgę append-only — tak aby historia jednego konta była małym, indeksowanym wycinkiem, nigdy skanem miliardów wierszy.** Wzorzec dostępu to zawsze „jedno konto, zakres dat", więc partycjonuj tak, by mu odpowiadał.

## Architektura

```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)
```

## Jak to działa

- **Partycjonuj po koncie + czasie.** Zahaszuj id konta do N bucketów, potem partycjonuj zakresowo po miesiącu. Zapytanie o jedno konto/miesiąc trafia dokładnie w jedną partycję — DB przycina resztę. To ogranicza każdy odczyt niezależnie od całkowitego rozmiaru.
- **Niezmienna księga.** Nigdy nie `UPDATE` transakcji; korekty to nowe wiersze odwracające. Daje to ścieżkę audytu, bezpieczną replikację i pozwala agresywnie cache'ować (wiersze nigdy się nie zmieniają).
- **Warstwowanie hot/cold.** Trzymaj ostatnie ~3 miesiące na szybkim SSD/Postgres dla odczytów o niskim latency; przetaczaj starsze partycje do **S3/Parquet** (odpytywane przez Athena/Trino) lub Glacier. 95% zapytań trafia w świeże dane, więc większość magazynu może być tania.
- **Keyset pagination.** Stronicuj przez `WHERE (ts, id) < (:last_ts, :last_id) ORDER BY ts DESC LIMIT 50` — nie `OFFSET`. Offset skanuje i odrzuca pominięte wiersze; keyset trafia w indeks bezpośrednio, O(1) na stronę.

## Perspektywa rozmowy kwalifikacyjnej

Rozmówca sonduje **wybór klucza partycji** i **paginację**. Dobre odpowiedzi mówią „partycjonuj po koncie"; świetne wyjaśniają, **dlaczego keyset bije OFFSET** przy głębokich stronach, dlaczego **księga jest niezmienna** (audytowalność, brak rywalizacji o blokady) i jak **warstwowanie** obniża koszt. Pułapką jest pojedyncza gigantyczna tabela z indeksem złożonym — działa, dopóki indeks nie przestanie mieścić się w RAM i każdy odczyt nie stanie się związany z dyskiem.

## Kompromisy i awarie

- **Klucz partycji trudno zmienić.** Wybierz konto+czas z góry; repartycjonowanie setek milionów wierszy później to projekt migracyjny.
- **Zapytania międzykontowe cierpią.** „Całkowity wolumen po wszystkich kontach" rozgałęzia się teraz po partycjach — przenieś je do rollupu OLAP.
- **Zimne odczyty są wolne.** Pobranie 3-letniego wyciągu z Glacier trwa minuty; ustaw oczekiwania użytkownika lub rozgrzej na żądanie.
- **Gorące partycje.** Konto-wieloryb lub bieżący miesiąc mogą być hotspotem; sub-partycjonuj lub cache'uj.
- **Kiedy nie:** miliony wierszy (nie setki milionów) mieszczą się w jednej indeksowanej tabeli Postgres — nie buduj warstwowania, którego nie potrzebujesz. Sięgnij po to w skali, gdy indeks pojedynczej tabeli przestaje mieścić się w pamięci.

Architektura

Jak to działa

Perspektywa rozmowy kwalifikacyjnej

Kompromisy i awarie

Powiązane pytania