Database Sharding

আপনার ডেটাবেসে ১০ বিলিয়ন user record। একটি SQL server-এ — disk full, query slow, backup রাত ভর। সমাধান: ১০টা DB-তে ভাগ করো — প্রত্যেকটিতে ১ বিলিয়ন। User-এর ID দেখে সঠিক DB-তে পাঠাও। এটাই Sharding।

Sharding কী?

Database Sharding = একটি বড় database-কে অনেক ছোট shard-এ ভাগ করা — প্রতিটি shard আলাদা সার্ভারে। একে horizontal partitioning-ও বলে।

প্রতিটি shard একটি স্বাধীন database — same schema কিন্তু data-র এক subset।

কেন Sharding?

• Storage scale: এক DB-এর disk limit ছাড়িয়ে যায়।
• Throughput scale: Read/write load একাধিক server-এ।
• Performance: ছোট index, fast query।
• Geographic distribution: User-এর কাছাকাছি data।
• Fault isolation: এক shard fail = অন্য shard unaffected।

Horizontal vs Vertical Partitioning

Sharding Strategies

১. Range-based Sharding

Shard key-এর range অনুযায়ী data বিতরণ।

• User ID 1-1M → Shard 1
• User ID 1M-2M → Shard 2
• User ID 2M-3M → Shard 3

সুবিধা: Range query সহজ। অসুবিধা: Hot spot — নতুন user সব এক shard-এ।

২. Hash-based Sharding

Shard key-এর hash থেকে shard নির্ধারণ।

সুবিধা: Uniform distribution। অসুবিধা: Range query কঠিন; resharding hard।

৩. Geographic Sharding

Location অনুযায়ী shard।

• Asia → Shard 1
• Europe → Shard 2
• America → Shard 3

সুবিধা: Latency কম, GDPR compliance। অসুবিধা: Cross-region query কঠিন।

৪. Directory-based Sharding

Lookup service শারীরিক ভাবে track করে কোন data কোথায়।

সুবিধা: Flexible। অসুবিধা: Lookup service single point of failure।

Shard Key নির্বাচন

Sharding-এর সবচেয়ে গুরুত্বপূর্ণ সিদ্ধান্ত — যা change করা পরে কঠিন।

ভালো Shard Key-র বৈশিষ্ট্য

• High cardinality: অনেক unique value (boolean না)।
• Uniform distribution: Hot spot এড়ানো।
• Common in queries: WHERE clause-এ থাকে।
• Stable: Value পরিবর্তন না।
• Co-locate related data: User-এর সব data একই shard-এ।

উদাহরণ

• Social media: user_id (good — high cardinality, common query)।
• E-commerce: customer_id।
• Multi-tenant SaaS: tenant_id।
• IoT: device_id + timestamp।

সমস্যা ও সমাধান

Hot Spot (Hot Partition)

এক shard-এ disproportionate load। উদাহরণ: Celebrity user-এর সব data এক shard-এ।

• সমাধান: Better hash function, salt, sub-shard।

Cross-shard Query

Multiple shard থেকে data — JOIN, GROUP BY। সাধারণত expensive।

• সমাধান: Denormalize, application-level merge, scatter-gather query।

Resharding (Rebalancing)

Shard count বদলালে সব data redistribute। Massive operation।

• সমাধান: Consistent hashing (পরের chapter)।

Distributed Transaction

Multiple shard touch করে এমন transaction — 2PC বা Saga।

Backup & Restore

Cross-shard consistency বজায় রেখে backup নিতে হয়।

Implementation

Application-level

App-এ shard logic — কোন shard-এ কোন data সেটা code-এ।

Middleware/Proxy

Vitess (YouTube), ProxySQL — proxy app ও DB-র মাঝে।

Built-in

MongoDB, Cassandra, DynamoDB-তে native sharding। App-এর কাছে transparent।

বাস্তব উদাহরণ

• Instagram: Postgres + custom sharding (user-based)।
• YouTube: Vitess on MySQL — billion-row scale।
• WhatsApp: User_id-based sharding।
• Discord: Cassandra auto-shard with consistent hashing।
• Twitter: User-based + tweet-based sharding।

কখন Shard করবেন?

Sharding শেষ অস্ত্র — আগে চেষ্টা করুন:

1. Vertical scaling (bigger server)
2. Read replica
3. Caching
4. Indexing & query optimization
5. Vertical partitioning
6. তারপর — sharding।

সাধারণ ভুল ধারণা

1. "আগেই shard করো": Premature optimization — বাস্তবে complexity-cost বেশি।
2. "Wrong shard key fixable": না — change করা catastrophic।
3. "Sharding = scale solved": না — operational overhead, debug কঠিন।

Best Practices

• Shard key carefully design — change করা যায় না সহজে।
• Consistent hashing ব্যবহার করুন resharding-এর জন্য।
• Cross-shard query এড়াতে data carefully co-locate।
• Monitoring per-shard — hot spot detect।
• Backup strategy আগে plan।
• Vitess বা MongoDB built-in sharding বিবেচনা।