24 سبتمبر 2025·5 دقيقة
UUID مقابل ULID مقابل المعرفات التسلسلية: اختيار المعرف المناسب لقاعدة بياناتك
UUID مقابل ULID مقابل المعرفات التسلسلية: تعلّم كيف يؤثر كل نوع على الفهرسة والفرز والشظرة واستيراد وتصدير البيانات بأمان في مشاريع واقعية.
UUID مقابل ULID مقابل المعرفات التسلسلية: تعلّم كيف يؤثر كل نوع على الفهرسة والفرز والشظرة واستيراد وتصدير البيانات بأمان في مشاريع واقعية.
يبدو اختيار المعرف مملاً في الأسبوع الأول. ثم تطلق المنتج، تنمو البيانات، وتظهر تلك القرار "البسيط" في كل مكان: الفهارس، عناوين URL، السجلات، التصديرات، والتكاملات.
السؤال الحقيقي ليس "أيها أفضل؟" بل "أي ألم تريد تجنبه لاحقًا؟" يصعب تغيير المعرفات لأنها تُنسخ إلى جداول أخرى، وتُخزّن مؤقتًا عند العملاء، وتعتمد عليها أنظمة أخرى.
عندما لا يتطابق المعرف مع تطور المنتج، تراه عادة في عدة أماكن:
دائمًا توجد مقايضة بين الراحة الآن والمرونة لاحقًا. المعرفات التسلسلية سهلة القراءة وغالبًا سريعة، لكنها قد تكشف أعداد السجلات وتجعل دمج المجموعات أصعب. UUIDs العشوائية ممتازة للتفرد عبر الأنظمة، لكنها تجهد الفهارس وأكثر صعوبة على البشر عند تفحص السجلات. ULIDs تهدف للتفرد العالمي مع ترتيب تقريبي حسب الوقت، لكنها لديها تكاليف تخزين وأدوات.
طريقة مفيدة للتفكير: لمن المعرف بالأساس؟
إذا كان المعرف بشكل أساسي للبشر (الدعم، التصحيح، التشغيل)، فالمعرفات الأقصر والقابلة للمسح غالبًا تفوز. إذا كان للآلات (كتابات موزعة، عملاء غير متصلين، نظم متعددة المناطق)، فالتفرد العالمي وتجنّب التصادمات أهم.
عندما يناقش الناس "UUID مقابل ULID مقابل المعرفات التسلسلية" فهم فعليًا يختارون كيف تحصل كل صف على تسمية فريدة. تلك التسمية تؤثر على سهولة الإدراج، الفرز، الدمج، ونقل البيانات لاحقًا.
المعرف التسلسلي هو عدّاد. تُعطي قاعدة البيانات 1، ثم 2، ثم 3، وهكذا (عادة مخزن كـ integer أو bigint). سهل القراءة، رخيص التخزين، وغالبًا سريع لأن الصفوف الجديدة تقع في نهاية الفهرس.
الـ UUID هو معرف 128-بت يبدو عشوائياً، مثل 3f8a.... في معظم الإعدادات يمكن توليده دون سؤال قاعدة البيانات عن الرقم التالي، لذلك أنظمة مختلفة يمكنها إنشاء المعرفات بشكل مستقل. المقايضة أن الإدراجات ذات المظهر العشوائي قد تُجهد الفهارس وتحتاج مساحة أكبر من bigint بسيط.
الـ ULID أيضًا 128-بت، لكنه مصمم ليكون مرتبًا تقريبًا حسب الزمن. عادةً ما تفرز ULIDs الأحدث بعد الأقدم، مع الحفاظ على التفرد العالمي. تحصل غالبًا على بعض فوائد "التوليد في أي مكان" مثل UUIDs مع سلوك فرز أكثر ودية.
ملخص بسيط:
المعرفات التسلسلية شائعة للتطبيقات ذات قاعدة بيانات واحدة والأدوات الداخلية. تظهر UUIDs عندما تنشأ البيانات عبر خدمات أو أجهزة أو مناطق متعددة. تحظى ULIDs بشعبية عندما تريد توليد معرفات موزعة وتهمك أيضًا سلوكيات الفرز أو "الأحدث أولًا".
المفتاح الأساسي عادة مدعوم بفهرس (غالبًا B-tree). فكر في ذلك الفهرس كدليل هاتفي مرتب: كل صف جديد يحتاج إدخالًا موضوعًا في الموضع الصحيح حتى تبقى عمليات البحث سريعة.
مع المعرفات العشوائية (UUIDv4 الكلاسيكي)، تدخل الإدخالات في كل أنحاء الفهرس. هذا يعني أن قاعدة البيانات تمس صفحات فهرس كثيرة، وتقسم الصفحات أكثر، وتؤدي عمليات كتابة إضافية. بمرور الوقت تحصل على تذبذب في الفهرس: عمل أكثر لكل إدراج، مزيد من أخطاء الكاش، وفهارس أكبر مما توقعت.
مع المعرفات المتزايدة غالبًا (serial/bigint، أو معرفات مرتبة زمنيًا مثل كثير من ULIDs)، تستطيع قاعدة البيانات عادة إضافة الإدخالات بالقرب من نهاية الفهرس. هذا أكثر ملاءمة للكاش لأن الصفحات الحديثة تبقى ساخنة، ويكون الإدراج أنعم عند معدلات كتابة أعلى.
حجم المفتاح مهم لأن مدخلات الفهرس ليست مجانية:
المفاتيح الأكبر تعني أن عددًا أقل من الإدخالات يتسع في صفحة فهرس واحدة. هذا يؤدي غالبًا إلى فهارس أعمق، مزيد من الصفحات التي تُقرأ لكل استعلام، ومزيدًا من الذاكرة المطلوبة لتبقى سريعة.
إذا كان لديك جدول "أحداث" مع إدراجات مستمرة، يمكن أن يبدأ المفتاح الأساسي UUID العشوائي بالشعور ببطيء أسرع من مفتاح bigint، حتى لو أن عمليات البحث عن صف واحد بقيت تبدو جيدة. إذا توقعت إدراجات كثيفة، فتكلفة الفهرسة عادة أول اختلاف عملي تلاحظه.
إذا أنشأت "تحميل المزيد" أو التمرير اللامتناهي، فستعرف ألم المعرفات التي لا تفرز جيدًا. "يفرز المعرف جيدًا" عندما يعطي الترتيب بسببه ترتيبًا مستقرًا وذو معنى (غالبًا وقت الإنشاء) فتكون الصفحات متوقعة.
مع المعرفات العشوائية (مثل UUIDv4)، تُبعثر الصفوف الأحدث. الترتيب حسب id لا يطابق الزمن، والتمرير بمنهجية الكورسر مثل "أعطني العناصر بعد هذا id" يصبح غير موثوق. عادةً ما تلجأ إلى created_at، وهذا جيد، لكن يجب أن تفعل ذلك بعناية.
ULIDs مصممة لتكون مرتبة تقريبًا حسب الزمن. إذا فرزت حسب ULID (كسلسلة أو بصيغتها الثنائية)، تميل العناصر الأحدث لأن تأتي لاحقًا. هذا يبسط ترقيم الصفحات لأن الكورسر يمكن أن يكون آخر ULID رأيته.
تساعد ULID على ترتيب زمني تقريبي للـ feeds، تسهيل الكورسر، وتقليل الإدراج العشوائي مقارنة بـ UUIDv4.
لكن ULID لا يضمن ترتيبًا زمنيًا مثاليًا عندما تُولّد العديد من المعرفات في نفس الملليثانية عبر عدة آلات. إذا كنت تحتاج ترتيبًا دقيقًا، فلا بدّ من طابع زمني حقيقي.
created_at أفضلالفرز حسب created_at غالبًا أكثر أمانًا عند استرجاع بيانات قديمة، استيراد سجلات تاريخية، أو الحاجة إلى فواصل واضحة. نمط عملي شائع هو الفرز بـ (created_at, id) حيث يكون id كفاصل فقط.
الشظرة (sharding) تعني تقسيم قاعدة بيانات إلى عدة قواعد أصغر بحيث كل شظية تحتوي جزءًا من البيانات. عادةً ما يفعل الفرق ذلك لاحقًا عندما تصبح قاعدة بيانات واحدة صعبة التوسيع أو تمثل نقطة فشل واحدة.
اختيارك للمعرف يمكن أن يجعل الشظرة إما سهلة أو مؤلمة.
مع المعرفات المتسلسلة (auto-increment serial أو bigint)، كل شظية ستولّد بسهولة 1, 2, 3.... نفس المعرف قد يوجد على شظايا متعددة. في المرة الأولى التي تحتاج فيها لدمج البيانات، نقل الصفوف، أو بناء ميزات عبر الشظايا، ستواجه التصادمات.
يمكنك تجنب التصادمات بالتنسيق (خدمة معرف مركزية، أو نطاقات لكل شظية)، لكن هذا يضيف أجزاء متحركة ويمكن أن يصبح عنق زجاجة.
تقلل UUIDs وULIDs الحاجة للتنسيق لأن كل شظية يمكنها توليد المعرفات بشكل مستقل مع مخاطرة صغيرة جدًا للتكرار. إذا تعتقد أنك قد تقسم البيانات عبر قواعد بيانات، فهذا واحد من أقوى الحجج ضد التسلسلات البحتة.
حل شائع هو إضافة بادئة شظية ثم استخدام تتابع محلي على كل شظية. يمكنك تخزينه كعمودين، أو تعبئته في قيمة واحدة.
ينجح ذلك، لكنه يخلق صيغة معرف مخصصة. يجب أن تفهم كل تكاملاتك هذه الصيغة، يتوقف الفرز عن أن يكون ترتيبًا زمنيًا عالميًا دون منطق إضافي، ونقل البيانات بين الشظايا قد يتطلب إعادة كتابة المعرفات (مما يكسر المراجع إذا كانت هذه المعرفات مشتركة).
اسأل سؤالًا واحدًا مبكرًا: هل ستحتاج يومًا لدمج بيانات من قواعد بيانات متعددة والحفاظ على ثبات المراجع؟ إن كانت الإجابة نعم، خطط لمعرفات فريدة عالميًا من اليوم الأول، أو خصص ميزانية لترحيل لاحق.
التصدير والاستيراد هو المكان الذي يتوقف فيه اختيار المعرف عن كونه نظريًا. اللحظة التي تنسخ فيها الإنتاج إلى بيئة اختبار، تسترجع نسخة احتياطية، أو تدمج بيانات من نظامين، تكتشف ما إذا كانت معرفاتك ثابتة وقابلة للنقل.
مع المعرفات التسلسلية، عادة لا يمكنك إعادة تشغيل الإدراجات في قاعدة بيانات أخرى وتوقع أن تبقى المراجع كما هي ما لم تحافظ على الأرقام الأصلية. إذا استوردت مجموعة فرعية من الصفوف (مثلاً 200 عميل وطلباتهم)، يجب أن تحمّل الجداول بالترتيب الصحيح وتحافظ على المفاتيح الأساسية نفسها. إن أعيد ترقيم أي شيء، تنكسر المفاتيح الأجنبية.
تولد UUIDs وULIDs خارج تتابع قاعدة البيانات، لذلك أسهل في النقل بين البيئات. يمكنك نسخ الصفوف، الاحتفاظ بالمعرفات، وتظل العلاقات متطابقة. هذا يساعد عند استرجاع نسخ احتياطية، القيام بتصديرات جزئية، أو دمج مجموعات بيانات.
مثال: صدر 50 حسابًا من الإنتاج إلى الاستيجن لاستخلاص خطأ. مع مفاتيح أساسية UUID/ULID، يمكنك استيراد تلك الحسابات بالإضافة إلى الصفوف المتعلقة (مشاريع، فواتير، سجلات) وتظل كل شيء يشير إلى الوالد الصحيح. مع المعرفات التسلسلية، غالبًا ما تنتهي ببناء جدول ترجمة old_id -> new_id وإعادة كتابة المفاتيح الأجنبية أثناء الاستيراد.
للاستيرادات الكبيرة، الأساسيات أهم من نوع المعرف:
يمكنك اتخاذ قرار جيد بسرعة إذا ركزت على ما سيؤلم لاحقًا.
created_at مقبولًا، فالـ UUIDs والتسلسلي كلاهما يعملان.BIGINT التسلسلي عادة أقل ضغطًا على B-tree. UUIDs العشوائية تسبب مزيدًا من التذبذب.الفخ الأكبر هو اختيار معرف لأنه شائع، ثم اكتشاف أنه يتصادم مع كيفية استعلامك أو التوسع أو مشاركة البيانات. معظم المشاكل تظهر بعد أشهر.
فشلات شائعة:
123, 124, 125، يمكن للناس تخمين السجلات المجاورة وفحص نظامك.علامات تحذير يجب معالجتها مبكرًا:
اختر نوع مفتاح أساسي واحد والتزم به عبر معظم الجداول. الخلط بين الأنواع (bigint في مكان، UUID في مكان آخر) يجعل الانضمامات، الـ APIs، والترحيلات أصعب.
قدّر حجم الفهرس عند مقاييسك المتوقعة. المفاتيح الأعرض تعني فهارس أساسية أكبر ومزيدًا من الذاكرة وIO.
قرر كيف ستقوم بالترقيم عبر الصفحات. إذا كنت ترقّم حسب المعرف، فتأكد أن للمعرف ترتيبًا متوقعًا (أو اقبل أنه لن يكون كذلك). إذا ترقّم حسب الطابع الزمني، فاindex created_at واستخدمه باستمرار.
اختبر خطة الاستيراد على بيانات شبيهة بالإنتاج. تحقق من إمكانية إعادة إنشاء السجلات دون كسر المفاتيح الأجنبية وأن إعادة الاستيراد لا تولّد معرفات جديدة صامتة.
اكتب استراتيجية التصادم: من يولد المعرف (القاعدة أم التطبيق)، وماذا يحدث إذا أنشأت نظامان سجلات دون اتصال ثم تم المزامنة لاحقًا؟
تأكد أن الروابط العامة والسجلات لا تكشف أنماطًا تهتم بها (أعداد السجلات، معدل الإنشاء، دلائل الشظية الداخلية). إذا استخدمت معرفات تسلسلية، افترض أن الناس يمكنهم تخمين المعرفات المجاورة.
مؤسس منفرد يطلق CRM بسيط: جهات اتصال، صفقات، ملاحظات. قاعدة Postgres واحدة، تطبيق ويب واحد، والهدف الرئيسي هو الإطلاق.
في البداية، يبدو المفتاح الأساسي serial bigint مثالياً. الإدراجات سريعة، الفهارس مرتبة، وسهل القراءة في السجلات.
بعد عام، يطلب عميل تقارير ربع سنوية لتدقيق، ويبدأ المؤسس باستيراد العملاء المحتملين من أداة تسويق. المعرفات التي كانت داخلية الآن تظهر في CSVs، رسائل البريد، وتذاكر الدعم. إذا استخدم نظامان 1, 2, 3... يصبح الدمج فوضويًا. تضطر لإضافة أعمدة مصدر، جداول ترميم، أو إعادة كتابة المعرفات أثناء الاستيراد.
بحلول السنة الثانية، يوجد تطبيق جوال يحتاج لإنشاء سجلات أثناء عدم الاتصال ثم المزامنة لاحقًا. الآن تحتاج معرفات يمكن توليدها على العميل دون التحدث لقاعدة البيانات، وتريد مخاطرة تصادم منخفضة عندما تهبط البيانات في بيئات مختلفة.
حل توافقي غالبًا ما يصمد:
إذا كنت محتارًا بين UUID وULID وserial، قرر بناءً على كيف ستتحرك بياناتك وتنمو.
خيارات سريعة لجمل واحدة للحالات الشائعة:
bigint مفتاحًا أساسيًا تسلسليًا.الخلط غالبًا هو أفضل جواب. استخدم bigint تسلسلي للجداول الداخلية التي لا تخرج من قاعدة بياناتك (جداول الربط، مهام الخلفية)، واستخدم UUID/ULID للكيانات العامة مثل المستخدمين، المؤسسات، الفواتير، وأي شيء قد تصدّره أو تزامنه أو تشير إليه من خدمة أخرى.
إذا كنت تبني في Koder.ai (koder.ai)، فمن المفيد تحديد نمط المعرفات قبل توليد الكثير من الجداول وواجهات البرمجة. وضع التخطيط واللقطات/التراجع في المنصة يسهل تطبيق والتحقق من تغييرات المخطط مبكرًا، بينما لا يزال النظام صغيرًا بما يكفي للتغيير بأمان.
ابدأ بالآلام المستقبلية التي تريد تجنبها: بطء الإدراج بسبب عمليات كتابة فهرس عشوائية، ترقيم صفحات محرج، ترحيلات خطرة، أو تصادمات معرفات أثناء الاستيراد والدمج. إذا كنت تتوقع أن تنتقل البيانات بين أنظمة أو تُنشأ في أماكن متعددة، افترِض معرفًا فريدًا عالميًا (UUID/ULID) مع إبقاء قضايا ترتيب الوقت منفصلة.
مفتاح bigint التسلسلي خيار قوي عندما تكون لديك قاعدة بيانات واحدة، وحجم الكتابة كبير، والمعرفات تبقى داخلية. هو مضغوط، سريع لفهارس B-tree، وسهل القراءة في السجلات. العيب الرئيسي أنه يصعب دمج البيانات لاحقًا بدون تصادمات، وقد يكشف أعداد السجلات إذا تم عرضه علنًا.
اختر UUIDs عندما تُنشأ السجلات في خدمات أو مناطق أو أجهزة متعددة أو عملاء غير متصلين وتحتاج إلى مخاطرة تصادم منخفضة جدًا دون تنسيق مركزي. تعمل UUIDs جيدًا أيضًا كمعرّفات عامة لأنها صعبة التخمين. المقايضة المعتادة هي فهارس أكبر وأنماط إدراج أكثر عشوائية مقارنة بالمفاتيح المتسلسلة.
ULIDs منطقية عندما تريد معرّفات يمكن توليدها في أي مكان وفي الوقت نفسه تكون تقريبًا مرتبة حسب الزمن. هذا يبسط ترقيم الصفحات بالمسار ويقلّل من مشكلة الإدراج العشوائي التي تراها في UUIDv4. لكن لا تعامل ULID كطابع زمني مثالي؛ استخدم created_at عندما تحتاج ترتيبًا صارمًا أو أمانًا عند استيراد بيانات قديمة.
نعم، خاصة مع UUIDv4 العشوائي على الجداول ذات الكتابة المكثفة. الإدراج العشوائي ينتشر عبر فهرس المفتاح الأساسي، مما يسبب مزيدًا من انقسامات الصفحات، وتبدّل ذاكرة التخزين المؤقت، وفهارس أكبر مع الوقت. غالبًا ما تلاحظ ذلك أولًا في معدلات إدراج مستمرة أبطأ وحاجة أكبر للذاكرة/القراءة والكتابة، أكثر من تأخر البحث عن صف واحد.
ترتيب حسب معرف عشوائي (مثل UUIDv4) لن يطابق وقت الإنشاء، لذا المؤشرات من نوع “بعد هذا المعرف” لا تعطي خطًا زمنيًا ثابتًا. الإصلاح الموثوق هو الترقيم حسب created_at وإضافة المعرف كفاصل، مثل (created_at, id). إذا أردت الترقيم حسب المعرف فقط، فمعرف قابل للترتيب زمنيًا مثل ULID أبسط عادة.
المعرفات المتسلسلة تتصادم عبر الشظايا لأن كل شظية ستولد 1, 2, 3... بشكل مستقل. يمكنك تجنب التصادمات بتنسيق (نطاقات لكل شظية أو خدمة معرف مركزية)، لكن هذا يضيف تعقيدًا تشغيليًا وقد يتحول إلى عنق زجاجة. UUIDs/ULIDs تقللان الحاجة للتنسيق لأن كل شظية يمكنها توليد معرفات بأمان من جانبها.
UUIDs/ULIDs أسهل لأنك تستطيع تصدير الصفوف واستيرادها في مكان آخر مع الحفاظ على العلاقات دون إعادة ترقيم. مع المعرفات التسلسلية، غالبًا ما تتطلب الاستيرادات الجزئية جدول ترجمة مثل old_id -> new_id وإعادة كتابة المفاتيح الأجنبية بعناية، وهو أمر سهل أن يحصل خطأ فيه. إذا كنت تنسخ بيئات أو تدمج مجموعات بيانات بانتظام، فالمعرفات الفريدة عالميًا توفر وقتًا كبيرًا.
نمط شائع هو وجود معرفين: مفتاح أساسي داخلي مضغوط (serial bigint) للكفاءات الداخلية والانضمامات، ومعرف عام ثابت (ULID أو UUID) للروابط والواجهات والتصدير. هذا يبقي قاعدة البيانات سريعة وفي نفس الوقت يجعل التكاملات والترحيلات أقل إيلامًا. المهم معاملة المعرف العام كقيمة ثابتة لا تُعاد استخدامها أو تفسيرها.
خطط لذلك مبكرًا وطبقها باستمرار عبر الجداول وواجهات البرمجة. في Koder.ai، قرر استراتيجية المعرف الافتراضية في وضع التخطيط قبل توليد الكثير من المخططات والنقاط النهائية، ثم استخدم اللقطات/التراجع للتحقق من التغييرات بينما المشروع لا يزال صغيرًا. أصعب جزء ليس إنشاء معرفات جديدة—بل تحديث المفاتيح الأجنبية، التخزين المؤقت، السجلات، والتكاملات الخارجية التي لا تزال تشير إلى القديم.