شاردینگ (Sharding)
شاردینگ: تقسیم داده بین چند دیتابیس؛ انتخاب کلید شارد، مشکلات Hotspot و Rebalancing و راه‌حل‌ها
شاردینگ چیست؟
وقتی «یک دیتابیس» جا نمی‌شود (داده یا نوشتن)، داده را افقی تقسیم می‌کنیم بین چند سرور مستقل — هر کدام «شارد» با زیرمجموعه داده.
کاربران A-J → شارد ۱
کاربران K-S → شارد ۲
کاربران T-Z → شارد ۳کلید شارد — مهم‌ترین تصمیم
چگونه تصمیم بگیریم داده کجا برود؟
| استراتژی | ایده | مشکل |
|---|---|---|
| Range | بازه (A-J) | Hotspot: همه به یک بازه! |
| Hash | hash(id) % n | توزیع یکنواخت ✓ اما rebalance سخت |
| Directory | جدول نگاشت مرکزی | انعطاف ✓ اما خودش تک‌نقطه! |
| Geo | جغرافیا | تأخیر محلی ✓ اما داده نامتوازن |
مشکلات شاردینگ
۱. Hotspot (نقطه داغ)
کلید بد = همه بار روی یک شارد. مثال: شارد بر اساس «تاریخ» → امروز همه! یا سلبریتی با ۱۰M فالوور در یک شارد.
۲. Cross-Shard Query
کوئری روی «همه داده» = پرسش از همه شاردها + ادغام:
«۵ پست محبوب کل سایت» → ۳ کوئری به ۳ شارد → mergeJoin بین شاردها؟ عملاً مرده!
۳. Rebalancing
شارد ۱ پر شد → داده جابه‌جا → با hash ساده (mod n)، همه داده‌ها جابه‌جا می‌شوند! راه‌حل: Consistent Hashing (مبحث آینده) یا شاردینگ با «بازه‌های مجازی».
۴. تراکنش توزیع‌شده
نوشتن در دو شارد = دو فاز commit (2PC) — کند و پیچیده! طراحی بهتر: داده مرتبط در یک شارد (user_id کلید، نه post_id).
چه زمانی شارد کنیم؟
- کش و بهینه‌سازی تمام شد؟
- Replica خواندن را حل کرد اما نوشتن گلوگاه است؟
- ذخیره‌سازی از سرعت رشد عقب است؟
شاردینگ آخرین راه است — پیچیدگی بزرگ! اول: کش، ایندکس، Read Replica، جداسازی جدول.
جمع‌بندی
- شاردینگ = تقسیم افقی داده بین سرورها
- کلید شارد: hash یکنواخت، range خطر hotspot
- مشکلات: cross-shard، rebalance، تراکنش
- آخرین گزینه — اول کش و replica!
این مبحث بخشی از دوره آموزش کامل طراحی سیستم (System Design) است.