Database sharding: data একাধিক server-এ ভাগ করা

একটি database server যখন আর data বা write ধরে রাখতে পারে না, তখন shard করতে হয়। Strategy, ব্যথার জায়গা এবং কেন এটি শেষ উপায়, জানুন।

NewsReport•২৬ অক্টোবর, ২০২৬•১ মিনিটে পড়া

Sharding হলো একটি বড় dataset-কে ছোট অংশে (shard) ভাঙা, যেখানে প্রতিটি shard নিজের database server-এ থাকে। প্রতিটি row ঠিক একটি shard-এর। এভাবেই write-heavy সিস্টেম এক মেশিনের সীমা পেরোয়।

Shard key

আপনি একটি shard key বাছেন (যেমন user_id), যা ঠিক করে row কোথায় যাবে। ভালো key data ও traffic সমানভাবে ছড়ায় এবং বেশিরভাগ query-তে থাকে।

Strategy

Range-based: user ১ থেকে ১০ লাখ shard A-তে, ১০ থেকে ২০ লাখ shard B-তে। range query সহজ, কিন্তু নতুন user সবাই সর্বশেষ shard-এ পড়ে।
Hash-based: hash(user_id) mod N shard ঠিক করে। সমানভাবে ছড়ায়, কিন্তু shard যোগ করলে অনেক data নড়ে (consistent hashing এর সমাধান, সেই পর্ব দেখুন)।
Directory-based: একটি lookup table প্রতিটি key-কে shard-এ ম্যাপ করে। নমনীয়, কিন্তু lookup নিজেই নতুন নির্ভরতা।

উত্তরাধিকারে পাওয়া সমস্যা

Hot shard। একজন বিখ্যাত user বা ব্যস্ত tenant একটি shard-কে ডুবিয়ে দেয়।
Cross-shard query। একাধিক shard জুড়ে join বা মোট হিসাব ধীর ও জটিল। ডিজাইন করুন যেন বেশিরভাগ query এক shard-এই থাকে।
Shard-এর মধ্যে transaction কঠিন। এড়ান, নয়তো eventual consistency মেনে নিন।
Resharding। পরে shard সংখ্যা বদলানো বড় migration।
পরিচালনা। আরও server-এর backup, monitoring ও upgrade।