როგორ ინახავთ 100M ლოგ event-ს დღეში?

Question

IT Interview Practice · Accepted Answer

ააგეთ **append-only pipeline: agent-ები → Kafka → tiered storage (ცხელი ClickHouse/ELK-ში, ცივი object storage-ში)** retention policy-ით, რომელიც უახლეს მონაცემს ინდექსავს და დანარჩენს იაფად არქივებს. 100M event/დღეში საშუალოდ ~1,200/წამია (spike-ები ბევრად მაღალი) და დღეში ათეულ-ასეულ GB — ოპტიმიზაცია გააკეთეთ იაფი write-ებისა და შემოსაზღვრული query ღირებულებისთვის, არა OLTP სემანტიკისთვის.

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

ლოგები write-once-ია, არასდროს განახლდება — ამიტომ ingest path არის **append**. agent-ები, როგორიც **Fluent Bit / Vector**-ია, ხაზებს **Kafka**-ს უგზავნიან, რომელიც burst-ებს ბუფერავს და producer-ებს storage-ისგან მიჯნავს. თუ ClickHouse maintenance-ისთვის ჩამქრალია, event-ები Kafka-ში დგება queue-ში და ხელახლა ეშვება — ლოგებს არ ყრით. batch write-ები (ათასობით მწკრივი თითო insert-ზე), რადგან per-row insert-ები throughput-ს ანგრევს columnar store-ებზე.

## Hot store: index ძებნისთვის

უახლეს ლოგებს სწრაფი ძებნა სჭირდება ("error-ები ბოლო საათში service X-ისთვის"). **ClickHouse** (columnar, კუმშავს 10x, სკანირებს მილიარდობით მწკრივს/წამში) ან **ELK stack** (Elasticsearch inverted index) ამას ემსახურება. partition გააკეთეთ დღე/service-ით, რომ query-ები რამდენიმე partition-ამდე შემოიფარგლოს. ეს tier ძვირია თითო GB-ზე, ამიტომ პატარად შეინახეთ — მხოლოდ ბოლო 7–30 დღე.

## Cold store: object storage + tiering

უფრო ძველი ლოგები **S3-ში Parquet-ად** გადადის — იაფი, durable, query-ებადი on demand Athena/Trino-ს მეშვეობით. **lifecycle policy** ცვლის S3 → Glacier → წაშლა თქვენს retention ლიმიტზე (მაგ. 1 წელი). ეს *tiering* არის ღირებულების მთავარი ბერკეტი: ცხელი storage შეიძლება 50-ჯერ ძვირი იყოს არქივზე.

## ინტერვიუს პერსპექტივა

ინტერვიუერები ამოწმებენ **index-vs-cost ტრეიდ-ოფს**: ყველაფრის ინდექსება შესანიშნავ ძებნას იძლევა, მაგრამ ბიუჯეტს ანგრევს; არაფრის ინდექსება იაფია, მაგრამ არა-query-ებადი. კარგი: "გამოიყენე ELK." შესანიშნავი: tier-ებად ყოფთ — ინდექსავთ უახლეს ცხელ ნაჭერს, დანარჩენს ცივად არქივებთ — და ასახელებთ Kafka-ს, როგორც buffer-ს, რომელიც ingestion-ს downstream outage-ის მიმართ მდგრადს ხდის.

**გავრცელებული ხაფანგი:** ყველა ლოგის Elasticsearch-ში სამუდამოდ ჩადება. ეს ყველაზე ძვირი ვარიანტია და მისი cluster ეცემა cardinality/retention-ზე, რომელიც არ დაგეგმეთ.

## ტრეიდ-ოფები და ჩავარდნის რეჟიმები

- **Retention vs cost:** უფრო გრძელი retention = ხაზოვანი storage-ის ზრდა; tier გააკეთეთ აგრესიულად.
- **Kafka backpressure:** თუ consumer-ები ჩამორჩნენ, დისკი ივსება — გაზომეთ retention და მონიტორეთ lag.
- **Cardinality explosion:** მაღალი-cardinality ველები (user_id) ES ინდექსებს ბერავს; sample გააკეთეთ ან ჩამოაგდეთ.
- **Query ღირებულება ცივ მონაცემზე:** Athena scan თითო TB-ზე ჯდება — partition გააკეთეთ Parquet-ს date/service-ით, რომ scan-ები შემოსაზღვრული დარჩეს.
- **At-least-once dupe-ები:** dedup გააკეთეთ event id-ზე, თუ ზუსტი count-ები მნიშვნელოვანია.

Append pipeline

Hot store: index ძებნისთვის

Cold store: object storage + tiering

ინტერვიუს პერსპექტივა

ტრეიდ-ოფები და ჩავარდნის რეჟიმები

დაკავშირებული კითხვები