انبار فروشگاه پر شده. ساختمان دوم اجاره میکنی و جنس را تقسیم میکنی: هر ساختمان مالک بخشی از کالاست. سؤال حیاتی: این جعبه به کدام ساختمان برود؟ در دیتابیس به این تقسیم میگویند Sharding.
وقتی داده یا نرخ نوشتن از توان یک ماشین گذشت، هر Shard برشی از داده را برمیدارد. انتخاب کلید، سرنوشت کوئریها را تعیین میکند. کلید بد یعنی یا یک ساختمان داغ میشود، یا هر سؤال باید به همه ساختمانها برود.
جعبه به کدام ساختمان؟
سه استراتژی رایج است. هر کدام یک شغل دارد و یک درد.
| استراتژی | روش | قوت | ضعف |
|---|---|---|---|
| Range | A–M به Shard 1، N–Z به Shard 2 | کوئری بازهای عالی | Hot Spot: دادههای جدید یا محبوب یکجا جمع میشوند |
| Hash | hash(key) % N | توزیع یکنواخت | کوئری بازهای سخت؛ عوض کردن N فاجعه است |
| Geo / Entity | هر منطقه یا مشتری در Shard خودش | داده نزدیک کاربر، ایزوله | عدم توازن مناطق |
مشکل hash % N و راهحلش
با hash(key) % 4، افزودن سرور پنجم یعنی تقریباً همه کلیدها جابهجا شوند — یک شب کابوس. Consistent Hashing حلش میکند: سرورها و کلیدها روی یک حلقه مینشینند؛ هر کلید به اولین سرور در جهت عقربهها میرود. افزودن یا حذف یک سرور فقط همسایههایش را جابهجا میکند — حدود 1/N داده. با Virtual Node — هر سرور فیزیکی صدها نقطه روی حلقه — توزیع هم یکنواخت میشود.
دردسرهای Sharding
تکه کردن انبار، پیچیدگی را برای همیشه به سیستم اضافه میکند. این سه تا را از روز اول ببین.
- Hot Key / Celebrity: پست یک سلبریتی همه ترافیک را به یک Shard میریزد. Cache جلوی آن، یا شکستن کلید — key#1 تا key#10.
- کوئری بین-Shard — JOIN سراسری، تراکنش سراسری — گران است. کلید را طوری انتخاب کن که ۹۵٪ کوئریها تکShard باشند. برای داده کاربری معمولاً user_id.
- Rebalancing باید تدریجی و آنلاین باشد. ابزار مدرن — Vitess، Citus، خود Cassandra — همین را میدهد؛ جابهجایی یکشبه نه.
به زبان ساده
Sharding یعنی انبار را بین چند ساختمان تقسیم کنی؛ کلید تقسیم باید با سؤال رایج جور باشد.
مثال واقعی
پیامهای یک گفتگو را با conversation_id روی یک Shard میگذاری تا تاریخچه تکساختمانی بماند.