traffic 100x வளரும்போது MySQL-ஐ எப்படி அளவிடுவீர்கள்?

Question

IT Interview Practice · Accepted Answer

நிலைகளில் அளவிடுங்கள்: **முதலில் reads-க்கு read replicas + caching, பிறகு writes-க்கு sharding (Vitess)** — மேலும் எல்லாவற்றிற்கும் முன் connection pooling சேர்க்கவும், ஏனெனில் அது மலிவான 10x. Reads மற்றும் writes வேறுபட்டு அளவிடுகின்றன, எனவே முதல் நாளிலேயே 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
```

## Step 0: connection pooling

ஒவ்வொரு MySQL connection-ம் memory மற்றும் ஒரு thread செலவழிக்கிறது. 100x traffic-இல் CPU-க்கு முன்னரே `max_connections`-ஐ தீர்த்துவிடுவீர்கள். **ProxySQL** அல்லது **PgBouncer** போன்ற ஒரு pooler ஆயிரக்கணக்கான app connections-ஐ சில நூறு DB connections மீது multiplex செய்கிறது. இது ஒரு config மாற்றம், rearchitecture அல்ல — முதலில் அதைச் செய்யுங்கள்.

## Step 1: reads-ஐ cache செய்

பெரும்பாலான workloads read-heavy (பெரும்பாலும் 90%+). hot rows-க்கு முன்னால் **Redis** வைக்கவும் — user profiles, product pages. ஒரு cache hit ஒருபோதும் MySQL-ஐத் தொடாது. cache-aside பயன்படுத்துங்கள்: read cache → miss → read DB → populate cache. இது மட்டுமே 100x-இன் பெரும்பகுதியை உறிஞ்சலாம்.

## Step 2: read replicas

**async read replicas** சேர்த்து SELECTs-ஐ அவற்றுக்கு, writes-ஐ primary-க்கு route செய்யுங்கள். இது reads-ஐ horizontally அளவிடுகிறது: N replicas ≈ N× read capacity. சிக்கல் **replication lag** — ஒரு replica milliseconds-முதல்-seconds பின்தங்கியிருக்கலாம், எனவே read-your-own-writes கவனம் தேவை (அந்த user-இன் reads-ஐ primary-க்கு route செய்யுங்கள், அல்லது cache-இலிருந்து படியுங்கள்).

## Step 3: writes-ஐ shard செய்

Replicas writes-க்கு உதவாது — ஒவ்வொரு write-ம் இன்னும் single primary-ஐ அடைகிறது. write throughput ஒரு box-ஐ saturate செய்யும்போது, **shard** செய்யுங்கள். **Vitess** (YouTube-இல் கட்டப்பட்டது) MySQL-க்கு முன்னால் அமர்ந்து sharding, query routing, மற்றும் app-ஐ மீண்டும் எழுதாமல் online resharding செய்கிறது. `user_id` மூலம் shard செய்யுங்கள், இதனால் பெரும்பாலான queries single-shard-ஆக இருக்கும்.

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

நேர்காணல் செய்பவர்கள் **ordering**-ஐக் கவனிக்கிறார்கள்: உடனடியாக shard செய்யும் வேட்பாளர்கள் replicas/caching read scaling-ஐ மிக மலிவாகத் தீர்க்கின்றன என்பதை அறியவில்லை என்பதை வெளிப்படுத்துகிறார்கள். நல்லது: "replicas மற்றும் ஒரு cache சேர்." சிறந்தது: நீங்கள் read path-ஐ write path-இலிருந்து பிரித்து, replicas-இன் விலையாக replication lag-ஐக் குறிப்பிட்டு, reads அல்ல *writes* தான் bottleneck ஆகும்போது மட்டுமே sharding-ஐ அறிமுகப்படுத்துகிறீர்கள்.

**பொதுவான பொறி:** உண்மையான bottleneck write throughput ஆக இருக்கும்போது "வெறும் read replicas சேர்." Replicas அதை *மோசமாக்குகின்றன* (primary மீது அதிக replication load).

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

- **Replication lag:** stale reads; critical reads-ஐ primary-க்கு pin செய்யுங்கள் அல்லது semi-sync replication பயன்படுத்துங்கள்.
- **Cache stampede:** expiry-இல் பல misses ஒரே நேரத்தில் DB-ஐ அடைகின்றன — locks அல்லது staggered TTLs பயன்படுத்துங்கள்.
- **Sharding complexity:** cross-shard joins மற்றும் transactions-ஐ இழக்கிறது; writes கட்டாயப்படுத்தும்போது மட்டுமே இதைச் செலுத்துங்கள்.
- **Failover:** primary இறப்பு automated promotion தேவை (Orchestrator); ஒரு stale promoted replica சமீபத்திய writes-ஐ இழக்கலாம்.

Step 0: connection pooling

Step 1: reads-ஐ cache செய்

Step 2: read replicas

Step 3: writes-ஐ shard செய்

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

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

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