باختصار: UUID v4 هو الخيار الافتراضي الآمن للمعرّفات الفريدة العشوائية، وULID أفضل حين تريد أيضًا معرّفات تُرتَّب حسب وقت الإنشاء، وNanoID مثالي حين تحتاج معرّفات قصيرة وملائمة للروابط. الثلاثة تتجنّب التنسيق بين الأنظمة، لكنها توازن بشكل مختلف بين الطول والقابلية للترتيب وسلوك الفهرس. يشرح هذا الدليل ماهية كلٍّ منها ومتى تلجأ إليها.
يتيح المعرّف الفريد لأنظمة مستقلة إنشاء سجلات دون سؤال خادم مركزي «ما الرقم التالي؟». هذا الاستقلال هو الجوهر: خدمتان، أو جهازان دون اتصال، يمكن لكلٍّ منهما إنشاء معرّف مع الثقة بأن القيم لن تتصادم.
ما هو UUID حقًّا
UUID قيمة من 128 بت، تُكتب عادةً في 36 حرفًا — 32 رقمًا ست عشريًا زائد أربع شرطات، مثل 550e8400-e29b-41d4-a716-446655440000. النسخة التي تريدها غالبًا هي UUID v4، التي تملأ 122 بتًا منها بالعشوائية، فتنتج نحو 5.3 × 10³⁶ قيمة ممكنة. لذا لا حاجة للتحسّب للتصادم: عليك توليد ما يقارب مليار مليار قيمة قبل أن يبلغ احتمال أي تصادم 50%.
«ضئيل» لا يعني «مستحيل»، لكن عمليًا يقدّم v4 التفرّد دون أي تنسيق مركزي.
UUID v4 مقابل v1
يُبنى UUID v1 من طابع زمني مع عنوان الشبكة (MAC) للجهاز المولِّد. هذا يجعل v1 مرتَّبًا زمنيًا تقريبًا، لكنه قد يكشف أين ومتى أُنشئ المعرّف — أحيانًا مسألة خصوصية. أما UUID v4 فيتخلّى عن ذلك لصالح العشوائية الخالصة: لا ترتيب، ولا بيانات وصفية مضمَّنة، ولا شيء يُكشف. لمعظم التطبيقات v4 هو الافتراضي الصحيح، وv1 يستحق فقط حين تريد تحديدًا مكوّنه الزمني.
ULID: قابل للترتيب بحكم التصميم
ULID أيضًا 128 بت، لكنه مُرمَّز في 26 حرفًا بنظام Crockford base32 بدل الست عشري بالشرطات. أول 48 بتًا طابع زمني بالميلي ثانية، والـ80 المتبقية عشوائية. ولأن الطابع الزمني في المقدمة، تُرتَّب ULID معجميًا بترتيب إنشائها: رتّب السلاسل تحصل على الترتيب الزمني مجانًا. خاصية مفيدة حقًّا: تجعل استعلامات «الأحدث أولًا» رخيصة وتُبقي إدراجات قاعدة البيانات مرتَّبة بدل أن تكون مبعثرة.
NanoID: قصير وملائم للروابط
يستخدم NanoID افتراضيًا 21 حرفًا من أبجدية آمنة للروابط، فيدخل في الرابط من دون ترميز مئوي. الطول قابل للضبط، ما يتيح الموازنة بين الحجم ومقاومة التصادم: المعرّفات الأقصر أنظف لكنها تترك عشوائية أقل، فأبقِها أطول للمعرّفات العامة أو عالية الحجم. يتألق NanoID لروابط المشاركة والمعرّفات العامة القصيرة وأينما بدا UUID من 36 حرفًا مرهِقًا في الرابط.
أيها كمفتاح لقاعدة البيانات؟
هنا للاختيار عواقب أداء حقيقية. UUID v4 صالح تمامًا كمفتاح أساسي، لكن عشوائيته تجعل الصفوف الجديدة تُدرَج في مواضع عشوائية من فهرس B-tree، ما يسبب التجزئة ومزيدًا من انقسامات الصفحات مع نمو الجدول. أما المعرّفات المرتَّبة زمنيًا — ULID، أو UUID v7 الأحدث — فتُدرَج بترتيب تصاعدي تقريبًا، ما يُبقي الفهرس متراصًّا والكتابة محلّية. عند اختيار مفتاح لجدول كبير كثيف الكتابة، فضّل معرّفًا مرتَّبًا زمنيًا؛ أما الجداول الصغيرة فنادرًا ما يهم الفرق.
أخطاء شائعة يجب تجنّبها
- كشف معرّفات صحيحة متسلسلة علنًا بينما أردت معرّفات غير قابلة للتخمين — تلك مهمة معرّف عشوائي لا عدّاد تلقائي.
- استخدام UUID v4 عشوائي كمفتاح متجمِّع لجدول ضخم ثم التساؤل عن سبب تباطؤ الإدراج.
- اقتطاع UUID «لتوفير المساحة» — تتخلّص من العشوائية التي تضمن التفرّد.
- تقصير NanoID أكثر من اللازم لمعرّف عالي الحجم فترفع خطر التصادم.
لائم المعرّف مع المهمة: استخدم مولّد UUID لإنشاء قيم v4 أو v1 أو ULID أو NanoID، واختر v4 للتفرّد العام، وULID حين يهم الترتيب، وNanoID حين يجب أن يعيش المعرّف داخل رابط.