أدوات المطور · مولد UUID
ULID وSnowflake وKSUID وUUIDv7: مقارنة المعرفات القابلة للفرز
· خلفية
uuid التشفير متصفح API
لا يتم فرز UUID العشوائية حسب وقت الإنشاء، لذلك تضع العديد من التنسيقات طابعًا زمنيًا أولاً. يقارن هذا المنشور ULID وSnowflake وKSUID وUUIDv7 من حيث التخطيط والحجم والرتابة والتوافق.
المعرفات العشوائية والفهرس الذي يكرهها - المشكلة التي تحلها المعرفات المرتبة زمنيا
تعمل UUIDs العشوائية v4 على تشتيت نقاط الإدراج عبر المفتاح الأساسي لشجرة B عند وصول سجلات جديدة، مما يتسبب في انقسام الصفحة وإعادة التنظيم. تؤدي عمليات الإدراج في مواضع عشوائية إلى خفض أداء الكتابة وزيادة تجزئة القرص بشكل ملحوظ. وتتحمل قواعد البيانات عالية الإنتاجية هذه التكلفة - ثمن المعرفات المستقلة وغير المنسقة - ولكن التكلفة حقيقية. إذا كنت بحاجة إلى UUIDs للفرز حسب وقت الإنشاء، فيمكنك تحسين خصائص الفهرس بشكل كبير عن طريق إضافة بادئة طابع زمني. ظهرت العديد من التنسيقات: ULID، وSnowflake، وKSUID، وRFC 9562 v7. يقوم كل منها بإجراء مقايضات مختلفة في الحجم (26 من الأحرف إلى 128 bits)، ودقة الطابع الزمني (من الثواني إلى النانو ثانية)، والتوافق UUID، وما إذا كان تنسيق مولد المعرف يتطلب مركزية. تظهر معايير قاعدة البيانات تحسنًا ملحوظًا في أداء الإدراج.
ULID — طابع زمني يبلغ 48 بت مللي ثانية بالإضافة إلى 80 بتات عشوائية في 26 حرف Crockford الأساسي المكون من 32 حرفًا، مع خيار رتيب
ULID (المعرف الفريد عالميًا والقابل للفرز المعجمي) يقوم بتشفير طابع زمني يبلغ 48 بت مللي ثانية وحمولة عشوائية تبلغ 80 بت في 26 أحرف من Crockford base32. يتم فرز تمثيل النص بشكل صحيح بترتيب معجمي، مما يجعل معرّفات ULID مناسبة للأنظمة التي يكون فيها ترتيب الطابع الزمني وقابلية القراءة مهمًا - معالجة السجل، والتتبع الموزع، والخدمات الصغيرة حيث يجب أن تكون المعرفات قابلة للقراءة بسهولة في المخرجات التي تواجه الإنسان. يقدم ULID متغيرًا رتيبًا حيث تعمل المعرفات المتعددة التي يتم إنشاؤها خلال نفس المللي ثانية على زيادة الجزء العشوائي بدلاً من التكرار، مما يضمن حتى دفعات المعرفات السريعة الحفاظ على ترتيب إنشاء صارم. المقايضة هي أن ULID ليس UUID: فهو لا يتناسب مع عمود قاعدة البيانات القياسي 128 بت UUID بدون تحويل الترميز. ULID تغطي الدقة حوالي 8925 سنة.
Snowflake — 64 معرفات بت من طابع زمني، ومعرف العامل والتسلسل، والتنسيق الذي يتطلبونه
Snowflake هو معرف 64 بت تم تصميمه في الأصل بواسطة Twitter، وتم تصميمه كطابع زمني 41 بت ميلي ثانية، ومعرف عامل 10 بت، ورقم تسلسلي 12 بت. يغطي الطابع الزمني 41 بت حوالي 69 سنة ويتجاوز في 2106، مما يتطلب تنسيقًا زمنيًا وتخطيطًا للترحيل. يميز معرف العامل المعرفات التي تم إنشاؤها بواسطة خوادم أو عمليات مختلفة - يجب أن يعرف كل مولد Snowflake معرف العامل الفريد الخاص به دون التعارض مع الآخرين. إن Snowflake هو 64 bits بدلاً من 128، مما يجعله نصف حجم UUID، وأسرع في الفهرسة، وأكثر كفاءة في التخزين لكل معرف. يتم فرزه حسب الوقت ومعرف العامل، وهو مفيد لتوجيه الطلبات أو السجلات حسب المصدر. العيب التشغيلي: يجب تعيين معرف عامل لكل مولد، ويجب الحفاظ على مزامنة الساعات.
KSUID — طابع زمني للثواني مع حمولة عشوائية كبيرة، مرتبة بالبايت
KSUID (معرف K-Sortable الفريد) هو معرف 128 بت يتكون من طابع زمني ثانوي لـ Unix 32-بت وحمولة عشوائية 96 بت، يتم ترميزها عادةً كـ 27 حرف أساسي 62. التنسيق قابل للفرز بترتيب معجمي، والجزء العشوائي سليم من الناحية المشفرة بالنسبة لحجمه. KSUID أقل اعتماداً على نطاق واسع من ULID أو Snowflake ولكنه يقدم دلالات مميزة: يتم فك تشفير الطابع الزمني بسهولة إلى ثانية يمكن قراءتها بواسطة الإنسان (مفيد في السجلات وتصحيح الأخطاء)، والجزء العشوائي 96 بت كبير بما يكفي بحيث لا يكون لمعرفات KSUID المتعددة التي تم إنشاؤها في نفس الثانية أي احتمال تكرار بدون تنسيق تسلسل. على عكس Snowflake، لا يتطلب KSUID أي تنسيق لمعرف العامل أو تخصيص مركزي. KSUID يعمل بالثواني بدلاً من المللي ثانية، لذلك يتم فرز المعرفات المتعددة خلال ثانية واحدة بشكل عشوائي ما لم تقم بتنفيذ منطق إضافي.
UUIDv7 - إجابة المسار المعياري التي تناسب أعمدة وأدوات uuid الموجودة
RFC 9562 v7 هو معرف 128 بت يتكون من طابع زمني Unix يبلغ 48 بت بالمللي ثانية، و12 bits بدقة أقل من مللي ثانية (يمكن استخدامه كعداد تسلسل)، و62 بتات عشوائية كلها مجتمعة. يتم فرزه بشكل صحيح كسلسلة معجمية وبايتات 128 بت في قواعد البيانات. والأهم من ذلك، أنه صالح UUID - فهو يضبط إصدار nibble على 7 والبتات المتغيرة على RFC 9562 القياسي، مما يجعله متوافقًا مع كل أداة وعمود قاعدة بيانات وAPI الذي يتعامل مع UUIDs. ليست هناك حاجة إلى تحويل الترميز، ولا تتطلب البنية الأساسية UUID الحالية أي تعديل. إذا تم إنشاء معرفات v7 متعددة في نفس المللي ثانية، فإن RFC 9562 توصي باستخدام الحقل الفرعي بالمللي ثانية كعداد رتيب بدلاً من البتات العشوائية. يمثل V7 خيارًا عمليًا للحفاظ على التوافق UUID.
الرتابة خلال ميلي ثانية واحدة - كيف يتعامل كل تنسيق مع الاندفاعات وسبب أهميته لطلب الضمانات
الرتابة هي الخاصية التي تنص على أنه في حالة وقوع حدثين بترتيب يمكن ملاحظته، تتم مقارنة معرفاتهما بنفس الترتيب. عند دقة مستوى المللي ثانية على الأجهزة الحديثة، تحدث أحداث متعددة بشكل روتيني خلال نفس علامة الساعة، لذلك يجب أن يتعامل أي نظام معرف قابل للفرز مع ترتيب أقل من المللي ثانية بشكل صحيح. يقدم ULID وضعًا رتيبًا صريحًا حيث يزيد الجزء العشوائي بدلاً من التوزيع العشوائي. يتضمن Snowflake رقمًا تسلسليًا يبلغ 12 بت والذي يزيد خلال علامة بالمللي ثانية. يفتقر KSUID إلى آلية مدمجة، لذا يتم فرز أحداث الثواني الفرعية عشوائيًا ما لم تتم إضافة منطق إضافي. RFC 9562 يوصي الإصدار 7 باستخدام الحقل الفرعي بالمللي ثانية كعداد رتيب. إذا كان نظامك يقوم بإنشاء آلاف UUIDs في الثانية، فإن الرتابة خلال المللي ثانية تؤثر بشكل كبير على ترتيب الاستعلام.
ما لا يغطيه هذا — معايير الإنتاجية، التي تعتمد على الأجهزة واللغة؛ يبقى المنصب النوعي
لا يتم تضمين مقاييس الإنتاجية وبيانات الأداء لأنها تعتمد بشكل كبير على بنية الأجهزة وتنفيذ اللغة ومحرك قاعدة البيانات واستراتيجية التخزين المؤقت. تختلف خصائص أداء قاعدة البيانات بشكل كبير حسب ما إذا كنت تقوم بقياس الإدخالات العشوائية أو استعلامات النطاق أو حمل الفهرس أو إجمالي الإنتاجية تحت حمل إنتاج واقعي. يظل المنشور نوعيًا، ويقارن التنسيقات من الناحية المفاهيمية بناءً على تصميماتها بدلاً من تقديم أرقام خاصة بالبيئة قد تكون مضللة. يتطلب تقييم الأداء في العالم الحقيقي إجراء اختبار في بيئتك الخاصة مع عبء العمل الخاص بك وقاعدة التعليمات البرمجية والقيود التشغيلية. تعد المقارنة بين تنسيقات المعرفات المختلفة بمثابة تمرين قيم.
الخلاصة: غالبًا ما يُقرر التوافق — يُنتج المولد ToolAcre معرفات UUID عشوائية؛ استخدم فحصه الجيد للتأكد من أن UUIDv7 من مكتبتك يتم توزيعه على أنه UUID
غالبًا ما يحدد التوافق التنسيق الذي سيتم اختياره. إذا كان مخطط قاعدة بياناتك يتطلب بالفعل UUID من الأعمدة، فإن الإصدار 7 هو الحل الحديث لقابلية الفرز دون مغادرة النظام البيئي UUID. في حالة إنشاء نظام جديد بأنواع معرفات مخصصة، فإن ULID يوفر تمثيلًا نصيًا أصغر ومزايا دقة بالمللي ثانية. إذا كنت بحاجة إلى سعة تخزينية تبلغ 64 بت ويمكنك إدارة تنسيق معرف العامل من خلال التخصيص المركزي، فإن Snowflake يعد خيارًا مثبتًا في الأنظمة كبيرة الحجم. تكون المفاضلة الأساسية بين التوافق القياسي (اختر الإصدار 7) والخصائص البديلة مثل الحجم الأصغر (Snowflake) أو إمكانية قراءة Base32 (ULID). قم باتخاذ الاختيارات بناءً على قيود النظام وقرارات النظام البيئي.