توضيح أرقام UUID — توقف عن استخدام الإصدار 4 في كل الأماكن

في مكان ما في كودك، هناك سطر يشبه هذا: id = uuid.v4(). يعمل. تمرير الاختبارات. لا يشتكي المستخدمون. وتعيش المديرة المختصة بسكونها كلما نظرت إلى خطة الاستعلام.

أصبحت UUID v4 الافتراضية لأنها بسيطة، متاحة عالميًا، ومقاومة للتصادم بما يكفي لكي لا تحدث تصادم حقيقي. لكن "يُستخدم" و"هو الأداة المناسبة" ليسا نفس الشيء — ولهذا فإن v4 يُسبب تباطؤ النظام بشكل فعلي مع التوسع.

ما الذي يفعله UUID v4 في قاعدة البيانات الخاصة بك؟

تستخدم قواعد البيانات النسبية أشجار B لمؤشرات المفاتيح الأساسية. تُحافظ الأشجار B على البيانات مرتبة بحيث يمكن للقاعدة أن تجد الصفوف في وقت O(log n). عند إدخال صف جديد، يجب على القاعدة أن تضعه في الموضع الصحيح في الأشجار المرتبة.

باستخدام UUID v4، كل معرف جديد عشوائي. 550e8400-e29b-41d4-a716-446655440000 قد يليه f47ac10b-58cc-4372-a567-0e02b2c3d479 — لا توجد علاقة بين الإدخالات المتتالية. يجب على القاعدة أن تنتقل إلى نود عشوائي في الشجرة كل مرة.

هذا يسبب مشكلتين عند التوسع:

• تفرع الصفحات: عندما تملأ صفحة نهائية في الشجرة، يجب على القاعدة أن تقسمها إلى صفحتين وتحديث الوالد. مع إدخالات عشوائية، تحدث التفرعات بانتظام عبر كل الأشجار — وليس فقط في النهاية.
• إغفالات المخزن: يحتفظ مخزن البيانات بصفحات مُستخدمة مؤخرًا في الذاكرة. الإدخالات المتسلسلة تضرب نفس "الصفحات الساخنة". أما الإدخالات العشوائية فتُوزع القراءات عبر كل الأشجار، مما يُسبب تدهور المخزن ويُجبر على قراءة الأقراص.

في جدول يحتوي على ملايين الصفوف ونطاق كتابة عالٍ، تُضاف هذه التجزئة إلى تأخير حقيقي. إذا أظهرت نتائج EXPLAIN ANALYZE أن عمليات التصفح في المؤشر تأخذ وقتًا أطول مما ينبغي، فقد يكون المعرف العشوائي جزءًا من التشخيص.

شجرة عائلة المعرفات UUID

UUID v1: التوقيتات، عناوين MAC، وسبب عدم استخدامه

كانت UUID v1 هي المعرف الأول "القابل للترتيب". تُعدّ توقيتًا بطول 60 بت في فترات 100 نانو ثانية منذ 15 أغسطس 1582، مُدمجة مع تسلسل الساعة وعنوان MAC للجهاز. النتيجة هي تقريبًا قابلة للترتيب زمنيًا.

الجزء المتعلق بعنوان MAC هو ما قتل v1. يُكشف عن معرف واجهة الشبكة للجهاز في كل معرف تُنشأ — لكل سجل مستخدم، لكل طلب، لكل حدث. أظهر الباحثون أن المعرفات v1 من نفس الجهاز قابلة للتنبؤ بمجرد أن تمتلك عينة واحدة. بدأت المؤسسات تتجنب استخدامه في أي شيء موجه للمستخدمين، وتم تقليل استخدام المكتبات المُعتمدة على v1.

UUID v4: عشوائي، آمن، وغير مناسب كمفاتيح أساسية

يحتوي UUID v4 على 122 بت من البيانات العشوائية (الباقية تُستخدم لتحديد النسخة). احتمال التصادم عند توليد مليار معرف هو تقريبًا 1 في 10^18. من الناحية العملية، فهو صفر.

هذا العشوائية هي المطلوب تمامًا للاستخدامات الأمنية مثل مفاتيح الأمان، معرفات الجلسات، مفاتيح واجهات برمجة التطبيقات، ومعرفات الاتصال في السجلات — أي شيء يحتاج إلى معرف لا يمكن التنبؤ به أو التعداد. في هذه الاستخدامات، استمر في استخدام v4. المشكلة هي أن "لا يمكن التنبؤ به" و"مُناسب للقاعدة" هما خصائص متعارضة.

تريد تجربة توليد المعرفات UUID؟ مولد المعرفات UUID على IO Tools يتيح لك إنشاء v1، v4، v7، وأشكال أخرى معًا لرؤية الفرق في الهيكل.

UUID v7: القيمة الافتراضية التي يجب أن تستخدمها

تم توحيد UUID v7 من قبل IETF في RFC 9562 في مايو 2023. يضع التوقيت بالثواني في 48 بت من الأعلى، متبوعًا بحقل نسخة بطول 4 بت، مُتسلسل بطول 12 بت، و62 بت من البيانات العشوائية.

ما يعنيه هذا عمليًا: المعرفات المولدة لاحقًا تكون أكبر من حيث الترتيب الهرمي. الإدخالات المتتالية تقع في مواقف متجاورة في الشجرة. لا توجد توزيع عشوائي، لا توجد تفرعات غير ضرورية، ولا توجد تهديدات في المخزن. يُظهر سلوك مفتاح تلقائي من نوع عدد مُتسلسل من منظور قاعدة البيانات — مع الحفاظ على التمييز العالمي دون تعاون.

يُضمن مُتسلسل التوقيت داخل نفس الثانية ترتيبًا متناقصًا حتى في مولدات عالية التردد. إذا أنشأت 10,000 معرف في ثانية واحدة، فسيتم ترتيبها بشكل صحيح. يحتفظ الجزء العشوائي بدرجة كافية من التباين بحيث يبقى احتمال التصادم بين أنظمة موزعة عظيمًا.

لأي نظام جديد يستخدم PostgreSQL أو MySQL أو قاعدة بيانات نسبية أخرى، يجب أن تكون UUID v7 القيمة الافتراضية للمفاتيح الأساسية.

ULID: البديل الذي جاء قبل UUID v7

كان ULID (مُعرف مُوحد مُرتّب ترتيبياً) يحل نفس المشكلة قبل أن يُعرف UUID v7. يستخدم 48 بت لتوقيت Unix بالثواني، متبوعًا بـ 80 بت من البيانات العشوائية، مُرموزة باستخدام Crockford's Base32.

النتيجة هي سلسلة بطول 26 حرفًا تبدو مثل 01ARZ3NDEKTSV4RRFFQ69G5FAV بدلاً من تنسيق المعرف المُقسّم بـ 36 حرفًا. هي آمنة للروابط دون تشفير، وتُرتّب بشكل صحيح كسلسلة، وتعمل بدون تباين الحروف.

لا يمتلك ULID معيار IETF — بل يمتلك معيار مجتمعي على ulid.github.io. هذا كافٍ لمعظم الفرق، ولكن إذا كنت في بيئة مُراقبة تتطلب معرفات مُعيارية رسمياً، فإن UUID v7 هي الخيار الأفضل. يمتلك ULID دعمًا قويًا في مكتبات JavaScript وGo، وإذا كان فريقك يُستخدمه بالفعل، فلا يوجد سبب عاجل للانتقال.

مقارنة جنبًا إلى جنب

ملكية	UUID v1	UUID versión 4	UUID v7	معرف الوحدة الموحدة
قابل للترتيب	جزئيًا	لا	نعم	نعم
مُقاوم للتصادم	نعم	نعم	نعم	نعم
مُناسب للقاعدة	جزئيًا	لا	نعم	نعم
مُحمي للخصوصية	لا (عنوان MAC)	نعم	نعم	نعم
مُعيار مُعتمد	IETF RFC 4122	IETF RFC 4122	IETF RFC 9562	مُعيار مجتمعي
طول معتاد	36 حرف	36 حرف	36 حرف	26 حرف
مصدر التباين	MAC + الساعة	عشوائي	التوقيت + العشوائية	التوقيت + العشوائية

متى تستخدم كل منها؟

UUID v7 — استخدم هذا للمفاتيح الأساسية في أي نظام جديد. هو معيار IETF، ويتمتع بدعم متزايد (مُدمج في PostgreSQL 17، متاح عبر مكتبات في كل لغة رئيسية)، ويُعطي ترتيبًا مُناسبًا للأشجار مع عدم الحاجة إلى تعاون.

UUID versión 4 — استمر في استخدامه لأي شيء يُعتبر مُهم من حيث الأمان، مثل مفاتيح الجلسات، مفاتيح إعادة تعيين الأذونات، مفاتيح واجهات برمجة التطبيقات، معلمات الاتصال في السجلات. التباين غير المُنبّه هو ميزة هنا، وليس عيبًا.

معرف الوحدة الموحدة — استخدمه إذا كان فريقك على استخدامه، خاصة في مشاريع JavaScript أو Go. التنسيق الأقصر يُظهر بشكل حقيقي في الروابط والسجلات. إذا كنت تبدأ من الصفر، فإن UUID v7 هو الخيار الأفضل على المدى الطويل فقط لأنه يمتلك دعمًا من IETF.

UUID v1 — لا. لا يوجد موقف يُعتبر مناسبًا لاستخدام v1 في كود جديد.

اعتبارات التحول

إذا كنت تدير نظامًا موجودًا يحتوي على مفاتيح أساسية من نوع UUID v4، فلا تحتاج إلى التحول فورًا — ولا يجب أن تفعل ذلك بسهولة. تُشير العلاقات الخارجية، ورمز التطبيق، وربما القيم المحفوظة في الذاكرة إلى هذه المعرفات. يتطلب التحول تخطيطًا دقيقًا وغالبًا ما يتطلب فترات صيانة.

لأغلب الفرق، النهج المُمارس هو: استخدام UUID v7 (أو ULID) لكل جداول جديدة وخدمات جديدة. قبول أن جداولك القديمة تحتوي على v4 وتحافظ على التجزئة من خلال إجراءات إعادة بناء المؤشرات بشكل دوري إذا كان التأثير على الأداء قابلًا للقياس. لا تسمح أن يكون المثالي عدوًا للجيد.

إذا كنت تبدأ مشروعًا جديدًا، وقاعدة بيانات جديدة، وجدولًا جديدًا، فلا يوجد سبب لاستخدام v4 كمفاتيح أساسية. الأدوات موجودة. أنشئ عينات من UUID v7 وأعد ما تتعامل معه.

الخلاصة

UUID v4 ليس خاطئًا — بل يُستخدم بشكل متكرر بشكل غير مناسب. تُعتبر عشوائية خاصية أمنية، وينبغي الحفاظ عليها حيث تُعتبر الأمان مهمًا. بالنسبة للمفاتيح الأساسية في قواعد البيانات، تتحول هذه العشوائية إلى عبئ على الأداء عند التوسع.

يحل UUID v7 المشكلة بشكل ناجح: متزايد بشكل تدريجي، مُميز عالميًا، معياري، ومتاح في قواعد البيانات والبرمجيات المُستخدمة. إذا كنت تُكتب نماذج قاعدة بيانات اليوم، فاعمل على v7 كقيمة افتراضية. سينظر إلى الفرق — وسألاحظه المدير المختص.

قد يعجبك أيضاً