Jak odpytać 10 mld rekordów poniżej 100 ms?

Question

IT Interview Practice · Accepted Answer

Projektuj **najpierw pod wzorzec dostępu (access pattern)**, potem dobierz partycjonowanie + właściwy indeks/PK, tak aby pojedyncze zapytanie dotykało małego, ograniczonego wycinka — nigdy nie skanowało 10 mld wierszy. Poniżej 100 ms przy 10 miliardach rekordów nie chodzi o szybszy dysk; chodzi o uczynienie zbioru roboczego maleńkim.

```text
Query ─▶ Router ──▶ Partition (by tenant/time) ──▶ Index/PK lookup ─▶ ~thousands of rows
   │                    (prune 99.9% of data)         (B-tree / sort key)
   └─▶ Cache (Redis) ─▶ hit? return in <5ms
                        miss ▼
                   Columnar store (ClickHouse) for aggregates / scans
```

## Wzorce dostępu napędzają wszystko

Zanim wybierzesz technologię, zapytaj: **point lookup czy range/aggregate?** „Pobierz ostatnie 20 zamówień użytkownika X" to zapytanie punktowe/zakresowe — chcesz, aby klucz partycji i klucz sortowania pasowały do niego dokładnie. „Zsumuj przychód wg regionu w tym miesiącu" to skan analityczny — row store to niewłaściwe narzędzie. Modelowanie zapytania jako pierwsze odróżnia projekt, który działa, od takiego, który wygląda rozsądnie, ale robi pełny skan.

## Partycjonowanie przycina przestrzeń wyszukiwania

Podziel tabelę po kluczu obecnym w każdym zapytaniu — zwykle **tenant_id + czas**. Z partycjami czasowymi zapytanie o „ostatnie 7 dni" czyta 7 partycji i ignoruje pozostałe 3 lata. To *partition pruning*: router eliminuje 99,9% danych, zanim jakikolwiek indeks zostanie sprawdzony.

## Właściwy projekt indeksu / PK

Wewnątrz partycji **klucz główny musi eksponować na początku kolumny filtra zapytania**. W DynamoDB: partition key = `tenant`, sort key = `timestamp` → zapytania zakresowe to O(log n) + odczyt sekwencyjny. W kolumnowym store'ze jak **ClickHouse** klucz sortowania (`ORDER BY (tenant, ts)`) pozwala silnikowi pomijać granule i czytać tylko pasujące bloki. Indeks pokrywający (covering) całkowicie unika dodatkowego pobrania wiersza.

## Wybór magazynu

- **Point lookupy, dużo zapisów:** NoSQL key-value (DynamoDB, Cassandra) — ~O(1) po kluczu, skaluje się poziomo.
- **Analityka/agregaty:** kolumnowy (ClickHouse, BigQuery) — czyta tylko potrzebne kolumny, wektoryzowany.
- **Cache'uj gorący 1%:** Redis z przodu absorbuje powtarzane odczyty w <5 ms; 10 mld wierszy, ale kilka milionów gorących kluczy.

## Perspektywa rozmowy kwalifikacyjnej

Rozmówca chce zobaczyć, jak mówisz **„jakie są zapytania?" przed „jaka baza?"**. Dobrzy kandydaci sięgają po indeksy; świetni zauważają, że indeks na 10 mld wierszy sam jest ogromny — więc *najpierw partycjonujesz, aby zmniejszyć to, co indeks pokrywa*. Nazwanie podziału row-vs-kolumnowy i warstwy cache sygnalizuje realne doświadczenie ze skalą.

**Częsta pułapka:** proponowanie jednego gigantycznego indeksu B-tree jako odpowiedzi. Pomaga on point lookupom, ale nic nie daje skanom analitycznym, a jego zapisy stają się wąskim gardłem przyjmowania danych.

## Kompromisy i tryby awarii

- **Zły klucz partycji** = scatter-gather między partycjami, latency puchnie. Wybierz klucz obecny w zapytaniach.
- **Gorąca partycja:** tenant-celebryta przytłacza jeden shard — dodaj sufiks saltujący.
- **Nieświeżość cache:** unieważniaj przy zapisie lub akceptuj opóźnienie TTL.
- **Koszt denormalizacji:** często duplikujesz dane per wzorzec dostępu; pamięć jest tania, 10-sekundowe zapytanie nie.

Wzorce dostępu napędzają wszystko

Partycjonowanie przycina przestrzeń wyszukiwania

Właściwy projekt indeksu / PK

Wybór magazynu

Perspektywa rozmowy kwalifikacyjnej

Kompromisy i tryby awarii

Powiązane pytania