Wie fragst du 10 Mrd. Datensätze unter 100ms ab?

Question

IT Interview Practice · Accepted Answer

Entwirf **zuerst für das Zugriffsmuster**, dann wähle Partitionierung + den richtigen Index/PK, sodass jede einzelne Abfrage nur einen kleinen, begrenzten Ausschnitt berührt - niemals 10 Mrd. Rows scannt. Sub-100ms über 10 Milliarden Datensätze geht es nicht um eine schnellere Platte; es geht darum, das Working Set winzig zu machen.

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

## Zugriffsmuster treiben alles

Bevor du Technik wählst, frage: **Point-Lookup oder Range/Aggregat?** "Hole die letzten 20 Bestellungen von Nutzer X" ist eine Point-/Range-Query - du willst, dass Partition und Sort Key exakt dazu passen. "Summiere den Umsatz pro Region diesen Monat" ist ein analytischer Scan - ein Row Store ist das falsche Werkzeug. Die Query zuerst zu modellieren ist es, was ein funktionierendes Design von einem trennt, das vernünftig aussieht, aber Full-Scans macht.

## Partitionierung beschneidet den Suchraum

Splitte die Tabelle nach einem Key, der in jeder Query vorkommt - meist **tenant_id + Zeit**. Mit Zeit-Partitionen liest eine Query für "letzte 7 Tage" 7 Partitionen und ignoriert die anderen 3 Jahre. Das ist *Partition Pruning*: Der Router eliminiert 99,9% der Daten, bevor irgendein Index konsultiert wird.

## Richtiges Index-/PK-Design

Innerhalb einer Partition muss der **Primary Key die Filterspalten der Query nach vorn stellen**. In DynamoDB: Partition Key = `tenant`, Sort Key = `timestamp` → Range Queries sind O(log n) + sequentielles Lesen. In einem Columnar Store wie **ClickHouse** lässt der Sorting Key (`ORDER BY (tenant, ts)`) die Engine Granules überspringen und nur passende Blöcke lesen. Ein Covering Index vermeidet den zusätzlichen Row Fetch vollständig.

## Store-Wahl

- **Point-Lookups, hoher Write:** NoSQL Key-Value (DynamoDB, Cassandra) - O(1)-artig per Key, skaliert horizontal.
- **Analytics/Aggregate:** Columnar (ClickHouse, BigQuery) - liest nur die benötigten Spalten, vektorisiert.
- **Cache die heißen 1%:** Redis davor absorbiert wiederholte Reads bei <5ms; 10 Mrd. Rows, aber ein paar Millionen Hot Keys.

## Interview-Perspektive

Der Interviewer möchte sehen, dass du **"Was sind die Queries?" vor "Welche Datenbank?"** sagst. Gute Kandidaten greifen zu Indizes; hervorragende merken an, dass ein Index auf 10 Mrd. Rows selbst riesig ist - deshalb *partitionierst du zuerst, um das zu verkleinern, was der Index abdeckt*. Die Row-vs-Columnar-Trennung und die Cache-Schicht zu benennen, signalisiert echte Skalierungserfahrung.

**Häufige Falle:** einen einzigen riesigen B-Tree-Index als Antwort vorzuschlagen. Er hilft Point-Lookups, tut aber nichts für die analytischen Scans, und seine Writes werden zum Ingestion-Engpass.

## Trade-offs & Fehlermodi

- **Falscher Partition Key** = Cross-Partition-Scatter-Gather, die Latency explodiert. Wähle einen Key, der in Queries vorkommt.
- **Hot Partition:** ein Celebrity-Tenant überlastet einen Shard - füge ein Salting-Suffix hinzu.
- **Cache-Staleness:** invalidiere bei Write oder akzeptiere TTL-Lag.
- **Denormalisierungskosten:** oft duplizierst du Daten pro Zugriffsmuster; Speicher ist günstig, eine 10-Sekunden-Query nicht.

Zugriffsmuster treiben alles

Partitionierung beschneidet den Suchraum

Richtiges Index-/PK-Design

Store-Wahl

Interview-Perspektive

Trade-offs & Fehlermodi

Ähnliche Fragen