MySQL ને scale કરવા તમે partitioning versus sharding તરફ ક્યારે વળો છો?

Question

IT Interview Practice · Accepted Answer

બંને એક મોટા table ને વિભાજિત કરે છે, પણ અલગ-અલગ સ્તરે. **Partitioning** એક table ને **એક જ MySQL server ની અંદર** અનેક files માં વિભાજિત કરે છે. **Sharding** ડેટાને **અનેક સ્વતંત્ર servers** પર વિભાજિત કરે છે. Partitioning એવા table ને મદદ કરે છે જે એક file માટે ખૂબ મોટું છે; sharding એવા workload ને મદદ કરે છે જે એક machine માટે ખૂબ મોટું છે.

## Partitioning (એક server)

```sql
CREATE TABLE events (
  id BIGINT, created_at DATETIME, payload JSON,
  PRIMARY KEY (id, created_at)          -- partition key must be in every unique key
) PARTITION BY RANGE (YEAR(created_at)) (
  PARTITION p2024 VALUES LESS THAN (2025),
  PARTITION p2025 VALUES LESS THAN (2026),
  PARTITION p2026 VALUES LESS THAN (2027)
);
-- Queries filtering on created_at hit ONE partition (partition pruning);
-- dropping old data is an instant ALTER TABLE ... DROP PARTITION p2024.
```

time-series અને સરળ archival માટે ઉત્તમ, પણ તે હજુ પણ એક જ server છે — વધુ total CPU, RAM, કે write throughput નહીં.

## Sharding (અનેક servers)

એક **shard key** (દા.ત. `user_id`) પસંદ કરો અને દરેક row ને hash કે range દ્વારા shard પર route કરો:

```
shard = hash(user_id) % N
  user 42 -> shard 2 (server B)     user 99 -> shard 0 (server A)
```

- **ફાયદા** — writes, storage, અને connections નું લગભગ-linear scaling.
- **ગેરફાયદા** — cross-shard JOINs અને transactions અઘરાં કે અશક્ય છે; ખરાબ shard key hotspots બનાવે છે; servers ઉમેરો ત્યારે **resharding** પીડાદાયક છે. high-cardinality, સમાનરૂપે-વિતરિત key પસંદ કરો અને એવી queries ટાળો જે બધા shards પર fan out કરવી પડે.

## કામગીરીનો ક્રમ

પહેલાં સસ્તા wins વાપરો: indexing, query tuning, read replicas, caching, પછી partitioning. Sharding તરફ ફક્ત ત્યારે વળો જ્યારે એક primary હવે **write** volume શોષી ન શકે — તે operational complexity માં સૌથી મોટો કૂદકો છે.

## આ શા માટે મહત્વનું છે

Scaling નિર્ણયો મોટે ભાગે અફર અને મોંઘા હોય છે. partitioning એ single-server organizational tool છે જ્યારે sharding એ distributed-systems પ્રતિબદ્ધતા છે — તેના shard-key અને cross-shard ખર્ચ સાથે — એ જાણવું teams ને અકાળે sharding કરવાથી કે partitioning એવી write-throughput ceiling ઉકેલશે એવી અપેક્ષા રાખવાથી અટકાવે છે જે તે નથી કરી શકતું.

Partitioning (એક server)

Sharding (અનેક servers)

કામગીરીનો ક્રમ

આ શા માટે મહત્વનું છે

સંબંધિત પ્રશ્નો