როგორ მასშტაბირებთ MySQL-ს, როცა ტრაფიკი 100-ჯერ იზრდება?

Question

IT Interview Practice · Accepted Answer

მასშტაბირება ეტაპებად: **read replica-ები + caching read-ებისთვის ჯერ, შემდეგ sharding (Vitess) write-ებისთვის** — და დაამატეთ connection pooling ყველაფრამდე, რადგან ეს ყველაზე იაფი 10x-ია. read და write სხვადასხვაგვარად მასშტაბირდება, ამიტომ ნუ მიდიხართ sharding-კენ პირველ დღეს.

```text
        ┌─▶ Cache (Redis) ── hit ──▶ return
App ─▶ Pool(PgBouncer/ProxySQL)      miss ▼
        │                    ┌─▶ Read replica 1 ┐
        ├──── reads ─────────┼─▶ Read replica 2 ┼─ (async replication)
        │                    └─▶ Read replica N ┘
        └──── writes ──▶ Primary ──▶ (later) Vitess shards ─▶ Primary A / Primary B
```

## ნაბიჯი 0: connection pooling

ყოველი MySQL connection მეხსიერებას და thread-ს ხარჯავს. 100x ტრაფიკზე `max_connections`-ს CPU-ზე დიდი ხნით ადრე ამოწურავთ. pooler-ი, როგორიც **ProxySQL** ან **PgBouncer**-ია, ათასობით app connection-ს რამდენიმე ასეულ DB connection-ზე multiplex-ს. ეს config ცვლილებაა, არა rearchitecture — გააკეთეთ ჯერ.

## ნაბიჯი 1: დააქეშეთ read-ები

უმეტესი workload read-heavy-ია (ხშირად 90%+). დააყენეთ **Redis** წინ ცხელი მწკრივებისთვის — user profile-ები, product page-ები. cache hit ვერასდროს ეხება MySQL-ს. გამოიყენეთ cache-aside: read cache → miss → read DB → populate cache. ეს მარტო შეიძლება შთანთქას 100x-ის უმეტესობა.

## ნაბიჯი 2: read replica-ები

დაამატეთ **async read replica-ები** და მიმართეთ SELECT-ები მათ, write-ები primary-ს. ეს ჰორიზონტალურად მასშტაბირებს read-ს: N replica ≈ N× read capacity. ხაფანგი არის **replication lag** — replica შეიძლება მილიწამებით-წამებით ჩამორჩეს, ამიტომ read-your-own-writes ყურადღებას მოითხოვს (მიმართეთ ამ მომხმარებლის read-ები primary-ს, ან წაიკითხეთ cache-იდან).

## ნაბიჯი 3: shard გაუკეთეთ write-ებს

replica-ები write-ს არ ეხმარება — ყოველი write მაინც ერთ primary-ს ხვდება. როცა write throughput ერთ ყუთს გაჯერავს, **shard გააკეთეთ**. **Vitess** (აშენებული YouTube-ში) MySQL-ის წინ დგას და აკეთებს sharding-ს, query routing-ს და online resharding-ს app-ის გადაწერის გარეშე. shard გააკეთეთ `user_id`-ით, რომ query-ების უმეტესობა single-shard დარჩეს.

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

ინტერვიუერები ამოწმებენ **თანმიმდევრობას**: კანდიდატები, რომლებიც მაშინვე shard-ს აკეთებენ, ცხადყოფენ, რომ არ იციან, რომ replica/caching read-ის მასშტაბირებას ბევრად იაფად წყვეტს. კარგი: "დაამატე replica-ები და cache." შესანიშნავი: მიჯნავთ read path-ს write path-ისგან, ასახელებთ replication lag-ს replica-ების ღირებულებად და sharding-ს მხოლოდ მაშინ ამატებთ, როცა *write*-ები — არა read-ები — არის bottleneck.

**გავრცელებული ხაფანგი:** "უბრალოდ დაამატე read replica", როცა ნამდვილი bottleneck write throughput-ია. replica-ები ამას *უარესს* ხდის (მეტი replication load primary-ზე).

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

- **Replication lag:** ძველი read-ები; მიამაგრეთ კრიტიკული read-ები primary-ს ან გამოიყენეთ semi-sync replication.
- **Cache stampede:** ბევრი miss ერთდროულად ხვდება DB-ს expiry-ზე — გამოიყენეთ lock-ები ან გადანაწილებული TTL-ები.
- **Sharding-ის სირთულე:** კარგავს cross-shard join-ებსა და transaction-ებს; გადაიხადეთ ეს მხოლოდ მაშინ, როცა write-ები აიძულებს.
- **Failover:** primary-ის სიკვდილს სჭირდება ავტომატური promotion (Orchestrator); ძველმა დაწინაურებულმა replica-მ შეიძლება უახლესი write-ები დაკარგოს.

ნაბიჯი 0: connection pooling

ნაბიჯი 1: დააქეშეთ read-ები

ნაბიჯი 2: read replica-ები

ნაბიჯი 3: shard გაუკეთეთ write-ებს

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

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

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