ஒரு நாளைக்கு 100M log events-ஐ எப்படிச் சேமிப்பீர்கள்?

Question

IT Interview Practice · Accepted Answer

ஒரு **append-only pipeline உருவாக்குங்கள்: agents → Kafka → tiered storage (hot ClickHouse/ELK-இல், cold object storage-இல்)** ஒரு retention policy உடன், இது சமீபத்திய data-ஐ index செய்து மீதத்தை மலிவாக archive செய்கிறது. 100M events/day என்பது சராசரியாக ~1,200/sec (spikes மிக அதிகம்) மற்றும் தினமும் பத்து-முதல்-நூறு GB — நீங்கள் OLTP semantics-க்கு அல்ல, மலிவான writes மற்றும் bounded query cost-க்கு optimize செய்கிறீர்கள்.

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

Logs write-once, ஒருபோதும் update ஆகாது — எனவே ingest path ஒரு **append**. **Fluent Bit / Vector** போன்ற agents lines-ஐ **Kafka**-க்கு அனுப்புகின்றன, இது bursts-ஐ buffer செய்து producers-ஐ storage-இலிருந்து decouple செய்கிறது. maintenance-க்காக ClickHouse down ஆனால், events Kafka-இல் queue ஆகி replay ஆகின்றன — நீங்கள் logs-ஐ drop செய்வதில்லை. Batch writes (ஒரு insert-க்கு ஆயிரக்கணக்கான rows) ஏனெனில் per-row inserts columnar stores-இல் throughput-ஐ அழிக்கின்றன.

## Hot store: search-க்காக index செய்

சமீபத்திய logs-க்கு விரைவான search தேவை ("service X-க்கு கடந்த மணி நேரத்தில் errors"). **ClickHouse** (columnar, 10x compress செய்கிறது, வினாடிக்கு பில்லியன் கணக்கான rows scan செய்கிறது) அல்லது **ELK stack** (Elasticsearch inverted index) இதை serve செய்கின்றன. day/service மூலம் partition செய்யுங்கள், இதனால் queries சில partitions-க்கு prune ஆகும். இந்த tier ஒரு GB-க்கு விலையுயர்ந்தது, எனவே அதைச் சிறியதாக வைக்கவும் — கடைசி 7–30 நாட்கள் மட்டுமே.

## Cold store: object storage + tiering

பழைய logs **S3-க்கு Parquet ஆக** நகர்கின்றன — மலிவானது, durable, Athena/Trino மூலம் on demand queryable. ஒரு **lifecycle policy** உங்கள் retention limit-இல் (எ.கா. 1 ஆண்டு) S3 → Glacier → deletion-ஆக transition செய்கிறது. இந்த *tiering* தான் மைய cost lever: hot storage archival-ஐ விட 50x விலை இருக்கலாம்.

## நேர்காணல் கண்ணோட்டம்

நேர்காணல் செய்பவர்கள் **index-vs-cost trade-off**-ஐ ஆராய்கிறார்கள்: எல்லாவற்றையும் index செய்வது சிறந்த search தருகிறது ஆனால் budget-ஐ ஊதிவிடுகிறது; எதையும் index செய்யாதது மலிவானது ஆனால் un-queryable. நல்லது: "ELK பயன்படுத்து." சிறந்தது: நீங்கள் tier செய்கிறீர்கள் — சமீபத்திய hot slice-ஐ index செய்து, மீதத்தை cold-ஆக archive செய்கிறீர்கள் — மேலும் downstream outages-க்கு ingestion-ஐ resilient ஆக்கும் buffer-ஆக Kafka-ஐக் குறிப்பிடுகிறீர்கள்.

**பொதுவான பொறி:** எல்லா logs-ஐயும் என்றென்றும் Elasticsearch-இல் வைப்பது. இது மிக விலையுயர்ந்த option மற்றும் அதன் cluster நீங்கள் திட்டமிடாத cardinality/retention மீது கவிழ்கிறது.

## சமரசங்களும் தோல்வி முறைகளும்

- **Retention vs cost:** நீண்ட retention = linear storage வளர்ச்சி; aggressively tier செய்யுங்கள்.
- **Kafka backpressure:** consumers lag ஆனால், disk நிரம்புகிறது — retention-ஐ size செய்து lag-ஐ கண்காணியுங்கள்.
- **Cardinality explosion:** high-cardinality fields (user_id) ES indexes-ஐ bloat செய்கின்றன; அவற்றை sample அல்லது drop செய்யுங்கள்.
- **Cold data மீது query cost:** Athena scans ஒரு TB-க்குச் செலவாகும் — Parquet-ஐ date/service மூலம் partition செய்யுங்கள், இதனால் scans bounded-ஆக இருக்கும்.
- **At-least-once dupes:** exact counts முக்கியமெனில் ஒரு event id மீது dedup செய்யுங்கள்.

Append pipeline

Hot store: search-க்காக index செய்

Cold store: object storage + tiering

நேர்காணல் கண்ணோட்டம்

சமரசங்களும் தோல்வி முறைகளும்

தொடர்புடைய கேள்விகள்