როგორ ითხოვთ 10B ჩანაწერს 100ms-ში?

Question

IT Interview Practice · Accepted Answer

დააპროექტეთ **access pattern-ისთვის ჯერ**, შემდეგ აირჩიეთ partitioning + სწორი index/PK, რომ ნებისმიერი ცალკე query ეხებოდეს პატარა, შემოსაზღვრულ ნაჭერს — არასდროს დაასკანიროთ 10B მწკრივი. 100ms-ზე ნაკლები 10 მილიარდ ჩანაწერზე არ ეხება უფრო სწრაფ დისკს; ის ეხება working set-ის პაწაწინად ქცევას.

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

## Access pattern-ები ყველაფერს განაპირობებს

ტექნოლოგიის არჩევამდე იკითხეთ: **point lookup თუ range/aggregate?** "აიღე მომხმარებელ X-ის ბოლო 20 order" არის point/range query — გინდათ, რომ partition და sort key ზუსტად ემთხვეოდეს მას. "შეაჯამე შემოსავალი რეგიონის მიხედვით ამ თვეს" არის ანალიტიკური scan — row store არასწორი იარაღია. query-ის ჯერ მოდელირება არის ის, რაც განასხვავებს დიზაინს, რომელიც მუშაობს, იმისგან, რომელიც გონივრულად გამოიყურება, მაგრამ full-scan-ს აკეთებს.

## Partitioning ამცირებს ძებნის სივრცეს

დაყავით ცხრილი გასაღებით, რომელიც ყოველ query-ში ჩნდება — ჩვეულებრივ **tenant_id + time**. time partition-ებით, "ბოლო 7 დღის" query 7 partition-ს კითხულობს და დანარჩენ 3 წელს უგულებელყოფს. ეს არის *partition pruning*: router 99.9% მონაცემს აშორებს ნებისმიერი index-ის კონსულტაციამდე.

## სწორი index / PK დიზაინი

partition-ის შიგნით **primary key უნდა აყენებდეს query-ის filter სვეტებს წინა პლანზე**. DynamoDB-ში: partition key = `tenant`, sort key = `timestamp` → range query-ები არის O(log n) + sequential read. columnar store-ში, როგორიც **ClickHouse**-ია, sorting key-ი (`ORDER BY (tenant, ts)`) საშუალებას აძლევს engine-ს გამოტოვოს granule-ები და მხოლოდ შესატყვისი block-ები წაიკითხოს. covering index მთლიანად არიდებს დამატებით row fetch-ს.

## Store-ის არჩევა

- **Point lookup-ები, მაღალი write:** NoSQL key-value (DynamoDB, Cassandra) — O(1)-ისებრი გასაღებით, ჰორიზონტალურად მასშტაბირდება.
- **ანალიტიკა/aggregate-ები:** columnar (ClickHouse, BigQuery) — მხოლოდ საჭირო სვეტებს კითხულობს, ვექტორიზებული.
- **დააქეშეთ ცხელი 1%:** Redis წინ შთანთქავს გამეორებით read-ებს <5ms-ში; 10B მწკრივი, მაგრამ რამდენიმე მილიონი ცხელი გასაღები.

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

ინტერვიუერს სურს დაინახოს, რომ ამბობთ **"რა არის query-ები?" "რომელი database?"-მდე**. კარგი კანდიდატები index-ისკენ მიდიან; შესანიშნავები აღნიშნავენ, რომ index 10B მწკრივზე თავად უზარმაზარია — ამიტომ *ჯერ partition-ით ამცირებთ, რასაც index ფარავს*. row-vs-columnar გაყოფისა და cache tier-ის დასახელება ნამდვილი მასშტაბის გამოცდილებას აჩვენებს.

**გავრცელებული ხაფანგი:** ერთი გიგანტური B-tree index-ის შეთავაზება პასუხად. ის ეხმარება point lookup-ებს, მაგრამ არაფერს აკეთებს ანალიტიკური scan-ებისთვის, და მისი write-ები ingestion-ის bottleneck-ია.

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

- **არასწორი partition key** = cross-partition scatter-gather, latency იბერება. აირჩიეთ გასაღები, რომელიც query-ებში ჩნდება.
- **Hot partition:** ცნობადი tenant ერთ shard-ს ტვირთავს — დაამატეთ salting suffix.
- **Cache-ის სიძველე:** invalidate write-ზე ან მიიღეთ TTL lag.
- **Denormalization-ის ღირებულება:** ხშირად ადუბლირებთ მონაცემს თითო access pattern-ზე; storage იაფია, 10-წამიანი query — არა.

Access pattern-ები ყველაფერს განაპირობებს

Partitioning ამცირებს ძებნის სივრცეს

სწორი index / PK დიზაინი

Store-ის არჩევა

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

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

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