توليد معرفات

1) لماذا الانتباه إلى محددات الهوية

• التفرد والنطاق (الاصطدامات والنمو الأفقي).
• الترتيب والفرز (ارتباط الوقت، التكرار، التخلص).
• أداء التخزين (الفهارس، الصفحات الساخنة، حجم المفتاح).
• السلامة (عدم القدرة على التنبؤ، التسريبات، التخمين).
• قابلية الاستخدام/التكامل (قصيرة، آمنة لعبارة URL، وليست حساسة للحالة).

يعد اختيار الهوية حلاً وسطًا بين الإنتروبيا وإمكانية الترتيب والطول ومعدل التوليد والاستغلال.

2) المتطلبات والشروط الرئيسية

التفرد: يجب أن يكون احتمال الاصطدام أقل من الخطر المقبول.
إنتروبي: «مقدار العشوائية» التي تحتوي على معرف (بت).
فرز الوقت/k-sortable-Lexicographic ≈ على أساس الوقت.
الرتابة: تسلسل غير متناقص داخل عقدة/تيار.
مكان الدخول: مقدار تركيز الإدراج الجديد في «ذيل» الفهرس (خطر الصفحات الساخنة).
القدرة على التنبؤ: هل من الممكن تخمين بطاقات الهوية المجاورة (مهمة للأمن/واجهة برمجة التطبيقات).
التمثيل: ثنائي/سلسلة، Base16/32/36/58/64، واصلات، علبة.

3) عائلات تحديد الهوية الرئيسية

3. 1 UUID

v4 (عشوائي): 122 بت من الإنتروبيا. مضطرب، جيد للسلامة والبساطة. ناقص: مؤشرات «فوضوية» بسبب التوزيع العشوائي - والتي، مع ذلك، تبدد الأحمال بالتساوي وتزيل «الصفحات الساخنة».
v1 (الوقت + MAC): الترتيب، ولكنه يحمل MAC/time (الخصوصية) ؛ في كثير من الأحيان.
v7 (مرتبة حسب الوقت): ميلي ثانية + جزء عشوائي. تصميم للفرز المعجمي حسب الوقت والضغط الجيد في قاعدة البيانات. حل وسط: يظهر «الذيل الساخن» للمؤشر ؛ يعالج بالتجزئة/البادئات/الزيادة.

نصائح

بالنسبة لواجهات برمجة التطبيقات الخارجية ومتطلبات الطلبات المتساهلة - v4.
لقواعد بيانات الأحداث/السجلات والمفاتيح «المصنفة» - v7.

3. 2 ULID (كروكفورد Base32)

128 بت: 48 بت من الزمن (ms) + 80 بت من العشوائية. مرتبة بشكل معجمي حسب الوقت، صديقة للرجل (بدون 'I، L، O، U')، خزنة URL. هناك اختلاف رتيبي (مع نفس الطابع الزمني، يزداد الجزء العشوائي).
الإيجابيات: إمكانية القراءة والترتيب وإمكانية النقل.
السلبيات: بتردد عالٍ جدًا من الإدخالات في وقت ما - «ذيل ساخن».

3. 3 KSUID

160 بت: 32 بت من الزمن (ثانية) بالنسبة للحقبة + 128 بت من العشوائية. نطاق زمني أكبر وفرز مستقر، سلاسل أقصر من ULID ؟ (ليس بعد الآن، ولكن مع ترميزه الخاص)، جيد لجذوع الأشجار والأشياء الموزعة.

3. 4 معرفات قشرية تشبه ندفة الثلج (k-sorable flakes)

[ timestamp bits ][ region/datacenter bits ][ worker bits ][ sequence bits ]

الخصائص: نمو رتيب على عقدة، تفرد شبه عالمي، تمثيل ثنائي قصير (64 بت).
المخاطر: الاعتماد على الساعة (الانجراف/الانحدار الزمني)، واستنفاد التسلسل في علامة واحدة، وتنسيق أجزاء المنطقة/العامل.
المعالجة: الحماية من «عودة الساعة»، تسلسل الاحتياطي، كاشف الوقت، انضباط PTP/NTP.

3. 5 تسلسلات DB (SEQUENCE/IDENTIVY)

أبسط جيل رتيب في واحد DBMS/shard.
الإيجابيات: قصيرة وسريعة ومريحة للطاولات المحلية.
السلبيات: صعبة على الصعيد العالمي في مجموعة موزعة ؛ يمكن التنبؤ به (غير آمن كمفتاح عام)، يخلق ذيلًا ساخنًا للمؤشر.

3. 6 معرفات المحتوى والعنوان (محتوى التجزئة)

المحتوى SHA-256/Blake3 → هوية ثابتة، تفريغ، فحص النزاهة، التخزين المؤقت.
الإيجابيات: الحتمية، الحماية من الاستبدال.
السلبيات: جيل باهظ الثمن (CPU)، الاصطدامات هي أصفار عملية، لا فرز للوقت، الطول.

4) الاصطدامات و «مفارقة عيد الميلاد» (بديهية)

p ≈ 1 - exp (-n (n-1 )/2/2 ^ b) ≈ n ^ 2/2 ^ (b + 1) (for small p)

• UUIDv4 (122 بت) في n = 10 ^ 12 (تريليون) → p ~ 1e-14 (ضئيل).
• 64 بت → عشوائية مع n = 10 ^ 9 بالفعل p ~ 0. 027 (خطر ملحوظ).
• الاستنتاج: عشوائية 64 بت غالبًا لا تكفي للأنظمة الضخمة ؛ استخدام 96/128 بت.

5) الفهارس والصفحات الساخنة والتخزين

تقوم المفاتيح العشوائية (v4) بتوزيع الإدخالات بالتساوي عبر شجرة الفهرس → لا يوجد «ذيل»، ولكن منطقة التخزين المؤقت أسوأ.
يتم إدخال (v7/ULID/Snowflake) مصنفة حسب الوقت «في الذيل» → موقع وضغط أفضل، ولكن خطر الصفحات الساخنة تحت تسجيل متوازي مرتفع.

• البادئات/الشحن حسب المستأجر/المنطقة (إضافة 1-2 بايت قبل الوقت) ؛
• التشابك: جزء من العشوائية في البتات العليا ؛
• مدخلات الدفعة، عامل حشو في شجرة B، الانتقال التلقائي إلى BRIN/تجميع جذوع الأشجار الكبيرة.

• 'UUID (16B)' vs 'BIGINT (8B) '/' INT8' يوفر الذاكرة/ذاكرة التخزين المؤقت ؛ Base32/58/64 الصفوف تزداد حجمها بنسبة 20-60% بالنسبة لقاعدة البيانات، قم بتخزين الثنائي، وتسلسل إلى سلسلة على الحافة.

6) الأمن والخصوصية

لا تستخدم SEQUENCE/INT كمعرفات عامة في عنوان URL/API: يمكن التخمين → عدد الموارد.
أضف معرفات عشوائية لا يمكن التنبؤ بها (v4/v7/ULID/KSUID) للمراجع الخارجية.
لا ترمز PII إلى ID. إذا كنت ترغب في تمكين السمة، قم بتشفير/إشارة (على سبيل المثال، JWE/JWS) أو استخدم الرموز المميزة غير الشفافة.
ترميزات URL-safe: Base32 Crockford, Base58 (بدون '0OI'), Base64url.

7) تعدد الإيجارات والبادئات والتوجيه

التنسيق: '[مستأجر _ بادئة] - [معرف]' أو ثنائي: 'مستأجر _ معرف | معرف |'.
الإيجابيات: المرشحات السريعة/الحفلات المستأجرة، الحماية من عمليات المسح N + 1.
السلبيات: قد تؤدي إلى تفاقم كثافة الإنتروبيا في البتات الأعلى → النظر في التوزيع (التجزئة البادئة).
لاحقة هاش (2-3 بايت) تقلل من الاصطدامات وتساعد على توجيه القطع: «شطر = هاش (معرف)% N».

8) توصيات عملية للاختيار

API، وصلات عامة، خدمات موزعة دون ترتيب صارم: UUIDv4، ULID/KSUID.
السجلات/الأحداث/الطلبات، حيث نقوم غالبًا بفرزها حسب الوقت: UUIDv7 أو ULID (رتيبة).
عرض النطاق الترددي فائق الارتفاع مع رتابة محلية ومفتاح قصير: 64 بت يشبه ندفة الثلج (الانضباط الزمني مطلوب).
خزائن القطع الأثرية/البناء/النقط: قابلة للعنونة بالمحتوى (SHA-256)، وفي الأعلى - «عرض» قصير مناسب للرجل (Hashids/link).
الجداول المحلية في قاعدة بيانات واحدة: SEQUENCE/IDENTIVY + «wraper» الخارجي للروابط العامة (القناع).

9) التنفيذ والأمثلة

9. 1 PostgreSQL

تخزين ثنائي UUID، الفهارس - «btree» أو «hash» حسب الحاجة.

sql
CREATE EXTENSION IF NOT EXISTS "uuid-ossp";

CREATE TABLE orders (
id uuid PRIMARY KEY DEFAULT gen_random_uuid(), -- или uuid_generate_v4()
created_at timestamptz NOT NULL DEFAULT now(),
tenant smallint NOT NULL
);

-- For time-sortable (UUIDv7) store binary (uuid), generation in the application.
-- If you want a cluster by time:
CREATE INDEX ON orders (created_at DESC);

sql
CREATE TABLE orders_t1 PARTITION OF orders FOR VALUES IN (1);
CREATE TABLE orders_t2 PARTITION OF orders FOR VALUES IN (2);

9. 2 Redis (عدادات ذرية/مونوتونيا)

bash
INCR "seq: orders" # local sequence combine: epoch_ms<<20     (worker_id<<10)      (seq & 1023)

9. 3 مولد يشبه ندفة الثلج (كاذب)

pseudo const EPOCH =  1704067200000  # custom epoch (ms)
state: last_ms=0, seq=0, worker=7, region=3

next():
now = epoch_ms()
if now < last_ms: wait_until(last_ms)    # защита от clock back if now == last_ms:
seq = (seq + 1) & ((1<<12)-1)      # 12 бит if seq == 0: wait_next_ms()
else:
seq = 0 last_ms = now return (now-EPOCH)<<22      region<<17      worker<<12      seq

9. 4 ULID/UUID في التطبيقات

اذهب

go
// ULID t:= time. Now(). UTC()
entropy:= ulid. Monotonic(rand. New(rand. NewSource(t. UnixNano())), 0)
id:= ulid. MustNew(ulid. Timestamp(t), entropy)

//UUID v7 (if there is a library)
id:= uuid. Must(uuid. NewV7())

عقدة. js

js import { ulid } from 'ulid';
import { v4 as uuidv4 } from 'uuid';
const id1 = ulid();
const id2 = uuidv4(); // v4

بايثون

python import uuid, time id_v4 = uuid. uuid4()
For v7, use a library (for example, uuid6/7 third-party packages)

10) الترميزات والتمثيلات

• Base32 كروكفورد (ULID): حالة غير حساسة، ولا توجد شخصيات متشابهة بصريًا.
• Base58: باختصار Base32/64 للرموز التي يمكن قراءتها من قبل الإنسان، آمنة من عنوان URL.
• Base64url: قصير، لكن «--» و «_» في عنوان URL.

تثبيت الحالة والشكل (الواصلات/لا شيء) لتجنب التكرار عند مقارنة الأوتار.

11) كتب اللعب الاختبارية وقابلية الملاحظة

الاصطدامات: مترية 'id _ collison _ total' (يجب أن تكون 0)، تنبيه في> 0.
توزيع البادئة: مخطط نسيجي للبايت العالي - نحن نبحث عن الشراء.
معدل التوليد: «ids _ per _ sec»، p99 زمن انتقال المولد.
انحراف الساعة (لـ Snowflake): العقد التعويضية، أحداث «عودة الساعة».
ذيول الفهرس: p95/p99 'أدخل' زمن الوصول ؛ نسبة الأقفال/الصفحات الساخنة.

• الحقن «انجراف الساعة/الخلف» → التأكد من أن المولد ينتظر/يبدل.
• «المعادلة» تفيض في مللي ثانية → next_ms شيك الانتظار.
• التوازي الجماعي → ما إذا كانت هناك عواصف من الأقفال في المؤشر.

12) الأنماط المضادة

AUTO_INCREMENT/SEQUENCE كهوية عامة: تخمين، تسريبات. استخدم بطاقة هوية عامة مبهمة على بطاقة داخلية.
UUIDv1 (MAC/time): الخصوصية.
هوية عشوائية 64 بت لكل تريليون إدخال: خطر حقيقي من الاصطدامات.
«المولد المركزي» العالمي بدون HA: SPOF وعنق الزجاجة.
معرفات مرتبة حسب الوقت بدون حماية ظهر الساعة: نسخ مكررة/تراجع النظام.
خلط تنسيقات الهوية المختلفة بدون نسخة/بادئة صريحة → الفوضى في النقاش/الهجرات.
حفظ الهوية كسلسلة مع سجلات/أشكال مختلفة → مكررة مخفية.

13) قائمة التنفيذ المرجعية

• نموذج مختار (v4/v7/ULID/KSUID/Snowflake/SEQ/hash) للاحتياجات من النطاقات.
• متطلبات الطلب المحددة (ما إذا كانت القابلية للفرز مطلوبة).
• تقدير احتمال الاصطدامات (ب بتات، ن أجيال) وتحديد عتبة الخطر.
• تم تصميم الترميز (ثنائي في DB + عرض يمكن قراءته من قبل الإنسان).
• لفرز الوقت - حماية على مدار الساعة، وحدود التسلسل وانضباط NTP/PTP.
• بالنسبة للهويات العامة - عدم القدرة على التنبؤ (عشوائية/ULID/KSUID)، عدم وجود PII.
• فكر في التجزئة (معرف)٪ N، البادئات متعددة المستأجرين.
• قابلية الملاحظة: الاصطدام، التوزيع، زمن الوصول، مقاييس انحراف الساعة.
• حالات اختبار التسلسل/الخلاف/طول النافذة.
• الشكل والنسخة والحقبة وخريطة البت ووثائق خطة الهجرة.

14) الأسئلة الشائعة

س: ماذا تختار «الافتراضي» للخدمات الدقيقة ؟

ج: UUIDv7 أو ULID: طلب الوقت، الكثير من الإنتروبيا، جيل بسيط على الحافة. بالنسبة لواجهات برمجة التطبيقات الخارجية، فإن ULID/UUIDv4 تقريبًا.

س: بحاجة إلى بطاقة هوية قصيرة ومقروءة من الإنسان.
ج: ULID/KSUID أو Base58-128-bit ترميز عشوائي/مؤقت للهوية. تذكر الطول والاصطدامات.

س: هل من الممكن عمل معرفات «رقمية قصيرة»، لكنها آمنة ؟

ج: نعم: قم بتخزين SEQ الداخلي، وفي الخارج أعط الرمز المميز المعتم (عشوائي 96-128 بت) أو Hashids بالملح + التوقيع.

س: كيف أهاجر من SEQ إلى UUIDv7 ؟

ج: أدخل عمودًا جديدًا «معرف _ جديد» (UUID)، ثنائي المسار، انشر إشارات إلى المعرف الجديد، ثم قم بتبديل مفاتيح DC/الأجنبية وحذف المفاتيح القديمة.

س: لماذا أصبحت إدخالات ULID الخاصة بي «ساخنة» ؟

ج: أدخل مفاتيح متزايدة بدقة في فهرس واحد. التقسيم/المستأجر، مزج البتات عالية الطلب، استخدم إدخالات الدفعة.

15) المجاميع

المعرف الجيد هو المجموعة الصحيحة من الخصائص للمشكلة: إنتروبيا كافية، فرز يمكن التنبؤ به (إذا لزم الأمر)، دعاية آمنة واستغلال صحي للمؤشرات. اختر UUIDv4/ULID/UUIDv7/KSUID للبساطة والتوزيع، Snowflake للرتابة الكثيفة والمفاتيح القصيرة (لانضباط الوقت)، تسلسلات للجداول المحلية، تجزئة المحتوى للقطع الأثرية. ضع قابلية الملاحظة والاختبارات - وستتوقف محددات الهوية عن كونها مصدرًا للمفاجآت.