MySQL-ஐ scale செய்ய partitioning எதிராக sharding-ஐ எப்போது நோக்கிச் செல்வீர்கள்?

Question

IT Interview Practice · Accepted Answer

இரண்டும் ஒரு பெரிய table-ஐப் பிரிக்கின்றன, ஆனால் வெவ்வேறு நிலைகளில். **Partitioning** ஆனது ஒரு table-ஐ **ஒற்றை MySQL server-க்குள்** பல files முழுவதும் பிரிக்கிறது. **Sharding** ஆனது data-ஐ **பல சுயாதீன servers** முழுவதும் பிரிக்கிறது. Partitioning ஆனது ஒரு file-க்கு மிகப் பெரிய ஒரு table-க்கு உதவுகிறது; sharding ஆனது ஒரு machine-க்கு மிகப் பெரிய ஒரு workload-க்கு உதவுகிறது.

## 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 தான் — அதிக மொத்த 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-இன் கிட்டத்தட்ட-நேர்கோட்டு scaling.
- **தீமைகள்** — cross-shard JOINs மற்றும் transactions கடினமானவை அல்லது சாத்தியமற்றவை; ஒரு மோசமான shard key hotspots-ஐ உருவாக்குகிறது; நீங்கள் servers-ஐச் சேர்க்கும்போது **resharding** வேதனையானது. ஒரு high-cardinality, சமமாக-விநியோகிக்கப்பட்ட key-ஐத் தேர்ந்தெடுத்து, அனைத்து shards-க்கும் fan out செய்ய வேண்டிய queries-ஐத் தவிர்க்கவும்.

## செயல்பாடுகளின் வரிசை

மலிவான வெற்றிகளை முதலில் தீர்த்துவிடுங்கள்: indexing, query tuning, read replicas, caching, பிறகு partitioning. ஒற்றை primary ஆனது **write** அளவை இனி உள்வாங்க முடியாதபோது மட்டுமே sharding-ஐ நோக்கிச் செல்லுங்கள் — இது operational complexity-இல் மிகப்பெரிய தாவலாகும்.

## இது ஏன் முக்கியம்

Scaling முடிவுகள் பெருமளவில் மீளமுடியாதவை மற்றும் விலையுயர்ந்தவை. partitioning என்பது ஒரு single-server organizational கருவி என்பதையும், sharding என்பது ஒரு distributed-systems அர்ப்பணிப்பு — அதன் shard-key மற்றும் cross-shard செலவுகளுடன் — என்பதையும் அறிவது, teams முன்கூட்டியே shard செய்வதிலிருந்தோ அல்லது partitioning தீர்க்க முடியாத ஒரு write-throughput உச்சவரம்பைத் தீர்க்கும் என்று எதிர்பார்ப்பதிலிருந்தோ தடுக்கிறது.

Partitioning (ஒரு server)

Sharding (பல servers)

செயல்பாடுகளின் வரிசை

இது ஏன் முக்கியம்

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