شناسه یکتای توزیع‌شده
شناسه یکتا در مقیاس بزرگ: مشکل Auto-Increment، UUID و الگوریتم Snowflake توییتر
مشکل: چه کسی شماره بعدی را می‌دهد؟
در تک‌سرور، AUTO_INCREMENT عالی است. اما با شاردینگ:
- شارد ۱ و ۲ هر دو رکورد «۱۰۰۱» می‌سازند — تصادم!
- مرکزی کردن شمارنده = تک‌نقطه‌شکست + گلوگاه!
راه‌حل ۱: UUID
۱۲۸ بیت تصادفی — تصادم عملاً صفر، بدون هماهنگی!
| ✓ مزایا | ✗ عیوب |
|---|---|
| بدون هماهنگی | ۱۶ بایت بزرگ + بی‌ترتیب |
| تولید محلی سریع | ایندکس B-Tree را می‌کُشد! |
| تصادم ~صفر | نامرتبسازی زمانی |
مشکل بزرگ: UUID تصادفی = «هرجا» در ایندکس درج می‌شود → صفحه‌بندی شکسته → نوشتن کند (Random I/O!).
راه‌حل ۲: Snowflake (توییتر)
۶۴ بیت مرتب‌شده زمانی و یکتا بدون هماهنگی:
[41 bit زمان][10 bit ماشین][12 bit توالی]
میلی‌ثانیه ۱۰۲۴ سرور ۴۰۹۶/میلی‌ثانیه
~۶۹ سال عمر | ۴ میلیون ID/ثانیه | مرتب زمانی ✓- مرتب زمانی: IDهای جدید > قدیمی → ایندکس append-only = سریع!
- بدون هماهنگی: هر سرور با ID خودش (۱۰ بیت ماشین)
- فشرده: ۸ بایت (نصف UUID)
مقایسه
| معیار | Auto-Increment | UUID | Snowflake |
|---|---|---|---|
| یکتایی توزیع‌شده | ✗ | ✓ | ✓ |
| مرتب زمانی | ✓ | ✗ | ✓ |
| اندازه | ۴-۸ بایت ✓ | ۱۶ بایت | ۸ بایت ✓ |
| ایندکس‌پسند | ✓✓ | ✗✗ | ✓✓ |
| هماهنگی لازم | مرکزی! | هیچ ✓ | هیچ ✓ |
نکات عملی
- UUIDv7 (جدید): زمانی + تصادفی — بهترین UUID!
- Snowflake نیاز: ساعت همگام (NTP) + ID ماشین یکتا
- برای URL عمومی: ID کوتاه + Base62 (مطالعه موردی!)
نکته مصاحبه: «چرا UUID نه؟» = «ایندکس تصادفی و بی‌ترتیب» — این پاسخ عمق شما را نشان می‌دهد. Snowflake را با ساختار بیتی‌اش توضیح دهید!
جمع‌بندی
- Auto-Increment با شاردینگ می‌میرد
- UUID: یکتا اما ایندکس‌کش
- Snowflake: زمانی + ماشین + توالی = کامل
- UUIDv7: نسل جدید UUID هوشمند
این مبحث بخشی از دوره آموزش کامل طراحی سیستم (System Design) است.