ایجاد شناسه ها

1) چرا به شناسه ها توجه می شود

• منحصر به فرد و مقیاس (برخورد، رشد افقی).
• ترتیب و مرتب سازی (همبستگی زمانی، تکرار، dedup).
• عملکرد ذخیره سازی (شاخص ها، صفحات داغ، اندازه کلید).
• ایمنی (غیر قابل پیش بینی بودن، نشت، حدس زدن).
• قابلیت استفاده/ادغام (کوتاه، URL امن، حساس به مورد).

انتخاب ID یک سازش بین آنتروپی، نظم، طول، نرخ تولید و بهره برداری است.

2) الزامات و شرایط کلیدی

منحصر به فرد بودن: احتمال برخورد باید کمتر از خطر قابل قبول باشد.
آنتروپی: «چقدر تصادفی» شامل ID (بیت) است.

مرتب سازی بر اساس زمان/k-sortable-Lexicographic ≈ time-based sorting

یکنواختی: یک توالی بدون کاهش در یک گره/جریان.
محل ورود: چقدر درج جدید در «دم» شاخص (خطر صفحات داغ) متمرکز شده است.
قابلیت پیش بینی: آیا می توان شناسه های همسایه را حدس زد (مهم برای امنیت/API).
نمایندگی: باینری/رشته، Base16/32/36/58/64، خطوط، مورد.

3) خانواده های شناسه اصلی

3. 1 شناسه کاربری

v4 (تصادفی): 122 بیت آنتروپی. اختلال، خوب برای ایمنی و سادگی. منهای: «هرج و مرج» شاخص با توجه به توزیع تصادفی - که، با این حال، به طور مساوی پراکنده بارهای و حذف «صفحات داغ».
v1 (زمان + MAC): ترتیب، اما MAC/زمان (حریم خصوصی) را حمل می کند ؛ اغلب اجتناب شود.
v7 (زمان سفارش): زمان میلی ثانیه + بخش تصادفی. طراحی برای مرتب سازی فرهنگ نویسی با زمان و فشرده سازی خوب در پایگاه داده. سازش: «دم داغ» شاخص ظاهر می شود ؛ درمان شده توسط shardening/prefixes/increment.

نکات

برای API های خارجی و الزامات سفارش lax - 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-sortable شناسه پوسته پوسته شدن)

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

خواص: رشد یکنواخت در یک گره، منحصر به فرد شبه جهانی، کوتاه (64 بیتی) نمایش دودویی.
خطرات: وابستگی به ساعت (رانش زمان/رگرسیون)، خستگی توالی در یک تیک، هماهنگی بیت های منطقه/کارگر.
درمان شده: حفاظت در برابر «عقب ساعت»، توالی ذخیره، آشکارساز زمان، نظم PTP/NTP.

3. 5 توالی DB (توالی/هویت)

ساده ترین نسل یکنواخت در یک DBMS/shard.
مزایا: کوتاه، سریع، مناسب برای جداول محلی.
معایب: دشوار در سطح جهانی در یک خوشه توزیع شده ؛ قابل پیش بینی (ناامن به عنوان یک کلید عمومی)، یک دم داغ از شاخص ایجاد می کند.

3. 6 شناسه محتوا آدرس (محتوای هش)

SHA-256/Blake3 محتوا → شناسه پایدار، deduplication، بررسی یکپارچگی، ذخیره سازی.
مزایا: جبرگرایی، حفاظت در برابر جایگزینی.
معایب: تولید گران قیمت (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) قرار داده شده «در دم» → محل بهتر و فشرده سازی، اما خطر صفحات داغ تحت ضبط موازی بالا.

• پیشوندها/sharding توسط مستاجر/منطقه (اضافه کردن 1-2 بایت قبل از زمان) ؛
• interleaving: بخشی از تصادفی در بیت بالاتر ؛
• درج دسته ای، پرکننده در درخت B، انتقال خودکار به برین/خوشه بندی برای سیاهههای مربوط بزرگ.

• 'UUID (16B)' در مقابل 'BIGINT (8B) '/' INT8' حافظه/حافظه پنهان را ذخیره می کند ؛ ردیف Base32/58/64 افزایش اندازه 20-60٪. برای پایگاه داده، ذخیره باینری، سریال به یک رشته در لبه.

6) امنیت و حریم خصوصی

از SEQUENCE/INT به عنوان شناسه های عمومی در URL/API استفاده نکنید: قابل حدس زدن → شمارش منابع.
اضافه کردن شناسه های تصادفی و غیر قابل پیش بینی (v4/v7/ULID/KSUID) برای مراجع خارجی.
PII را به ID رمزگذاری نکنید. اگر می خواهید ویژگی را فعال کنید، رمزگذاری/نشانه (به عنوان مثال، JWE/JWS) یا استفاده از نشانه های مبهم.
رمزگذاری URL امن: Base32 Crockford، Base58 (بدون '0OIl')، Base64url.

7) چند اجاره، پیشوندها و مسیریابی

فرمت: [TENANT _ PREFIX] - [ID] یا باینری: 'tenant _ id | id'.
مزایا: فیلترهای سریع/احزاب مستاجر، حفاظت در برابر اسکن N + 1.
معایب: ممکن است چگالی آنتروپی را در بیتهای بالاتر بدتر کند → توزیع (هش پیشوند) را در نظر بگیرید.
پسوند هش (2-3 بایت) برخوردها را کاهش می دهد و به مسیریابی shard کمک می کند: 'shard = hash (id)% N'.

8) توصیه های عملی برای انتخاب

API، لینک های عمومی، خدمات توزیع شده بدون نظم دقیق: UUIDv4، ULID/KSUID.
سیاهههای مربوط/حوادث/سفارشات، که در آن ما اغلب بر اساس زمان مرتب سازی: UUIDv7 یا ULID (یکنواخت).
پهنای باند فوق العاده بالا با یکنواختی محلی و کلید کوتاه: برف ریزه مانند 64 بیتی (نظم و انضباط زمان مورد نیاز).
غرفه مصنوعات/ساخت/حباب: محتوا آدرس (SHA-256)، و در بالا - یک «ویترین» کوتاه دوستانه (Hashids/link).
جداول محلی در یک پایگاه داده: SEQUENCE/IDENTITY + «بسته بندی» خارجی برای لینک های عمومی (پوشش).

9) پیاده سازی و نمونه

9. 1 PostgreSQL

ذخیره UUID باینری، شاخص - «btree» یا «هش» به عنوان مورد نیاز است.

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 ردیس (شمارنده اتمی/مونوتونیا)

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 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 Crockford (ULID): غیر حساس، بدون شخصیت های بصری مشابه.
• Base58: به طور خلاصه Base32/64 برای نشانه های قابل خواندن انسان، URL امن است.
• Base64url: کوتاه، اما «-» و «_» در URL.

تثبیت مورد و فرمت (خط تیره/هیچ کدام) برای جلوگیری از تکراری در هنگام مقایسه رشته.

11) تست playbooks و قابلیت مشاهده

برخورد: متریک 'id _ collision _ total' (باید 0 باشد)، هشدار در> 0.
توزیع پیشوند: هیستوگرام بایت های بالا - ما به دنبال خرید هستیم.
نرخ تولید: 'ids _ per _ sec'، تأخیر ژنراتور p99.
انحراف ساعت (برای Snowflake): گرههای افست، رویدادهای «ساعت به عقب رفت».
دم فهرست: p95/p99 'INSERT' تأخیر ؛ نسبت قفل/صفحات داغ.

• تزریق «رانش ساعت/عقب» → مطمئن شوید که ژنراتور در انتظار/تعویض است.
• 'sequence' سرریز در میلی ثانیه → چک انتظار next_ms.
• موازی سازی جرم → آیا طوفان قفل در شاخص وجود دارد.

12) ضد الگوهای

AUTO_INCREMENT/SEQUENCE به عنوان یک شناسه عمومی: حدس زده شده، نشت. از یک شناسه عمومی مات بیش از یک داخلی استفاده کنید.
UUIDv1 (MAC/TIME): حریم خصوصی.
شناسه تصادفی 64 بیتی در هر تریلیون ورودی: خطر واقعی برخورد.
جهانی «ژنراتور مرکزی» بدون HA: SPOF و تنگنا.
شناسه های مرتب شده با زمان بدون حفاظت از ساعت: تکراری/رگرسیون سفارش.
مخلوط کردن فرمت های مختلف شناسه بدون نسخه صریح/پیشوند → هرج و مرج در بحث/مهاجرت.
ذخیرۀ شناسه به عنوان رشتهای با ثباتها/فرمهای مختلف → تکرارهای پنهان.

13) چک لیست پیاده سازی

• فرمت انتخاب شده (v4/v7/ULID/KSUID/Snowflake/SEQ/hash) برای نیازهای دامنه.
• سفارش مورد نیاز تعریف شده (آیا مرتب سازی مورد نیاز است).
• احتمال برخوردها (b بیت، n نسل) تخمین زده می شود و آستانه خطر تعیین می شود.
• رمزگذاری طراحی شده است (باینری در DB + ویترین قابل خواندن انسان).
• برای زمان مرتب شده اند - ساعت تماس حفاظت، محدودیت توالی و نظم و انضباط NTP/PTP.
• برای شناسه های عمومی - غیر قابل پیش بینی (تصادفی/ULID/KSUID)، عدم وجود PII.
• فکر کردن هش (id)٪ N، پیشوندهای چند مستاجر.
• قابلیت مشاهده: برخورد، توزیع، تأخیر، معیارهای انحراف ساعت.
• موارد تست سرریز توالی/مشاجره/طول پنجره.
• فرمت، نسخه، دوره، بیت مپ و اسناد برنامه مهاجرت.

14) سوالات متداول

س: چه چیزی برای «پیش فرض» برای میکروسرویس ها انتخاب می شود ؟

A: UUIDv7 یا ULID: سفارش زمان، بسیاری از آنتروپی، نسل ساده در لبه. برای API های خارجی، ULID/UUIDv4 نیز تقریبا.

Q: نیاز به یک شناسه کوتاه و قابل خواندن برای انسان است.
A: ULID/KSUID یا Base58-128-bit رمزگذاری تصادفی/موقت ID. به یاد داشته باشید در مورد طول و برخورد.

س: آیا می توان شناسه های «عددی کوتاه» را ایجاد کرد، اما امن است ؟

A: بله: SEQ داخلی را ذخیره کنید و خارج از نشانه مات (تصادفی 96-128 بیت) یا Hashids با نمک + امضا کنید.

س: چگونه می توانم از SEQ به UUIDv7 مهاجرت کنم ؟

A: یک ستون جدید 'id _ new' (UUID)، دو مسیر را وارد کنید، منابع را به شناسه جدید منتشر کنید، سپس کلید DC/خارجی را تغییر دهید و قدیمی را حذف کنید.

س: چرا درج ULID من «داغ» شد ؟

A: کلید های به شدت افزایش یافته را به یک شاخص وارد کنید. پارتیشن/مستاجر، بیت های با سفارش بالا را مخلوط کنید، از درج دسته ای استفاده کنید.

15) مجموع

یک شناسه خوب مجموعه درستی از خواص برای مشکل است: آنتروپی کافی، مرتب سازی قابل پیش بینی (در صورت لزوم)، تبلیغات ایمن و بهره برداری سالم از شاخص ها. UUIDv4/ULID/UUIDv7/KSUID را برای سادگی و توزیع انتخاب کنید، Snowflake برای یکنواختی متراکم و کلیدهای کوتاه (برای نظم زمان)، توالی برای جداول محلی، هش محتوا برای مصنوعات. قابلیت مشاهده و تست ها را کنار بگذارید - و شناسه ها منبع شگفتی نخواهند بود.