Hogyan tárolsz napi 100M log eseményt?

Question

IT Interview Practice · Accepted Answer

Építs egy **append-only pipeline-t: agentek → Kafka → rétegzett tárolás (forró ClickHouse-ban/ELK-ben, hideg object storage-ben)** egy retention policyvel, amely a friss adatokat indexeli és olcsón archiválja a többit. 100M esemény/nap átlagosan ~1200/mp (a csúcsok sokkal magasabbak) és napi tíz-száz GB — az olcsó írásokra és a korlátozott lekérdezési költségre optimalizálsz, nem OLTP szemantikára.

```text
App/agents ─▶ Kafka ─▶ Consumers ─┬─▶ ClickHouse / ELK   (hot: last 7–30d, indexed, fast search)
 (Fluent Bit)  (buffer,            │
                replay)            └─▶ S3/Parquet         (cold: 90d–years, cheap, scan-on-demand)
                                          │
                                   Lifecycle/tiering ─▶ Glacier (archive) ─▶ delete at retention
```

## Append pipeline

A logok write-once-ok, sosem frissülnek — így a beolvasási út egy **append**. Az olyan agentek, mint a **Fluent Bit / Vector**, sorokat szállítanak a **Kafkába**, amely pufferelí a burstöket és szétcsatolja a producereket a tárolástól. Ha a ClickHouse karbantartás miatt leáll, az események a Kafkában sorakoznak és replayelnek — nem dobsz el logokat. Batchelj írásokat (soronként ezer sor insertenként), mert a soronkénti insertek tönkreteszik a throughputot az oszlopos tárolókon.

## Forró store: indexelj kereséshez

A friss logoknak gyors keresés kell ("hibák az elmúlt órában az X szolgáltatásnál"). A **ClickHouse** (oszlopos, 10x-esen tömörít, milliárdnyi sort/mp szkennel) vagy az **ELK stack** (Elasticsearch inverted index) szolgálja ezt ki. Partícionálj nap/szolgáltatás szerint, hogy a lekérdezések néhány partícióra metsződjenek. Ez a réteg drága GB-onként, ezért tartsd kicsinek — csak az utolsó 7–30 napot.

## Hideg store: object storage + rétegzés

A régebbi logok **S3-ba mint Parquet** kerülnek — olcsó, tartós, igény szerint lekérdezhető Athenán/Trinón át. Egy **lifecycle policy** átvisz S3 → Glacier → törlés a retention limitednél (pl. 1 év). Ez a *rétegzés (tiering)* a fő költségkar: a forró tárolás akár 50x-e lehet az archív árának.

## Interjú szemszög

Az interjúztatók az **index-vs-költség kompromisszumot** vizsgálják: mindent indexelni nagyszerű keresést ad de felrobbantja a büdzsét; semmit nem indexelni olcsó de lekérdezhetetlen. Jó: "használj ELK-t." Kiváló: rétegezel — indexeled a friss forró szeletet, archiválod a többit hidegen — és megnevezed a Kafkát mint a puffert, amely a beolvasást ellenállóvá teszi a downstream kiesésekkel szemben.

**Gyakori csapda:** minden logot örökre Elasticsearchbe tenni. Ez a legdrágább opció és a fürtje eldől azon a kardinalitáson/retentionön, amit nem terveztél be.

## Kompromisszumok és hibamódok

- **Retention vs költség:** hosszabb retention = lineáris tárhely-növekedés; rétegezz agresszíven.
- **Kafka backpressure:** ha a consumerek lemaradnak, megtelik a lemez — méretezd a retentiont és monitorozd a laget.
- **Kardinalitás-robbanás:** a magas kardinalitású mezők (user_id) felduzzasztják az ES indexeket; mintavételezd vagy dobd el őket.
- **Lekérdezési költség hideg adaton:** az Athena szkenek TB-onként fizetnek — partícionáld a Parquetet dátum/szolgáltatás szerint, hogy a szkenek korlátozottak maradjanak.
- **At-least-once duplikációk:** dedupelj egy event id-n, ha a pontos számok számítanak.

Append pipeline

Forró store: indexelj kereséshez

Hideg store: object storage + rétegzés

Interjú szemszög

Kompromisszumok és hibamódok

Kapcsolódó kérdések