Identifikatorlarni yaratish

1) Nega identifikatorlarga e’tibor berish kerak

• O’ziga xosligi va ko’lami (to’qnashuvlar, gorizontal o’sish).
• Tartib va saralash (vaqtinchalik korrelyatsiya, replikatsiya, dedup).
• Saqlash quvvati (indekslar, issiq sahifalar, kalit oʻlchami).
• Xavfsizlik (oldindan aytib bo’lmaydigan, oqish, taxmin qilish).
• Foydalanuvchanlik/integratsiya (qisqa, URL-safe, registrga sezgir emas).

ID tanlash - entropiya, tartibga solinish, uzunlik, ishlab chiqarish tezligi va foydalanish o’rtasidagi murosadir.

2) Asosiy talablar va atamalar

O’ziga xoslik: qarama-qarshilik ehtimoli maqbul xavfdan past bo’lishi kerak.
Entropiya: «qancha baxtsiz hodisalar» ID (bit) ni o’z ichiga oladi.
Tartibga solinishi (time-sortable/k-sortable): leksikografik saralash ≈ vaqt boʻyicha saralash.
Monotoniya: tugun/oqim ichidagi ketma-ketlik.
Yozuvning lokalizmi: yangi ilova indeksning «dumida» qancha toʻplangan (issiq sahifalar xavfi).
Oldindan aytish mumkin: qo’shni ID (xavfsizlik/API) ni taxmin qilish mumkinmi?
Taqdimot: binar/satr, Base16/32/36/58/64, defis, registr.

3) Identifikatorlarning asosiy oilalari

3. 1 UUID

v4 (random): 122 entropiya biti. Tartibsiz, xavfsizlik va soddalik uchun yaxshi. Minus: tasodifiy taqsimot tufayli indekslar «tartibsiz» bo’lib qoladi - ammo bu yuklarni bir tekis tarqatib yuboradi va «issiq sahifalar» ni olib tashlaydi.
v1 (time + MAC): tartibga solamiz, lekin MAS/vaqt (maxfiylik) olib boradi; ko’pincha qochishadi.
v7 (time-ordered): millisekundlik vaqt + random qismi. Zamon bo’yicha leksikografik saralash va DBda yaxshi siqish uchun dizayn. Murosa: indeksning «issiq dumi» paydo bo’ladi; shardatsiya/prekf/inkrement bilan davolanadi.

Maslahatlar

Tashqi API va tartibga qo’yiladigan qat’iy bo’lmagan talablar uchun - v4.
Hodisa/log DB va «saralanadigan» kalitlar uchun - v7.

3. 2 ULID (Crockford Base32)

128 bit: 48 bit vaqt (ms) + 80 bit tasodifiy. Leksikografik jihatdan vaqtga qarab saralanadi, insonparvar (’I, L, O, U’), URL-safe. Bir xil vaqt belgisi bilan tasodifiy qismi kattalashadi.
Afzalliklari: o’qish, tartibga solish, chidamlilik.
Kamchiliklar: qo’shimchalar chastotasi juda yuqori bo’lganda, bir vaqtda - «issiq quyruq».

3. 3 KSUID

160 bit: 32 bit vaqt (sek) + 128 bit tasodifiy davr. Katta vaqt oralig’i va barqaror saralanishi, ULIDdan qisqa satrlar? (yo’q - uzunroq, lekin kodlash bilan), taqsimlangan loglar va obyektlar uchun yaxshi.

3. 4 Snowflake-ga o’xshash (k-sortable flake IDs)

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

Xossalari: uzelda monoton o’sish, kvazi-global o’ziga xoslik, qisqa (64 bit) binar ko’rinish.
Xavflar: soatga bog’liqlik (vaqt dreyf/regress), bir tikda sequence tugashi, region/worker bitlarini muvofiqlashtirish.
Davolanadi: «clock back» dan himoyalanish, sequence zaxirasi, vaqt detektori, PTP/NTP intizomi.

3. 5 DB ketma-ketligi (SEQUENCE/IDENTITY)

Bitta MBB/shardda eng oddiy monoton avlod.
Ijobiy tomonlari: qisqa, tez, mahalliy jadvallar uchun qulay.
Kamchiliklar: global miqyosda taqsimlangan klasterda qiyin; oldindan aytib bo’lmaydigan (ommaviy kalit kabi xavfli), indeksning issiq dumini yaratadi.

3. 6 Kontent-manzilli ID (hash content)

Tarkibidan SHA-256/Blake3 → barqaror ID, deduplikatsiya, yaxlitlikni tekshirish, keshlash.
Afzalliklari: determinizm, almashtirishdan himoya qilish.
Minuslar: qimmatbaho avlod (CPU), amaliy nol to’qnashuvlar, vaqtinchalik saralash yo’q, uzunligi.

4) To’qnashuvlar va «tug’ilgan kunlar paradoksi» (intuitiv)

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

• UUIDv4 (122 bit) n = 10 ^ 12 (trillion) → p ~ 1e-14 (e’tiborsiz).
• 64 bitli random → n = 10 ^ 9 bo’lganda allaqachon p ~ 0. 027 (sezilarli xavf).
• Xulosa: 64-bit tasodifiy ko’pincha ulkan tizimlar uchun kam; 96/128 bitdan foydalaning.

5) Indekslar, issiq sahifalar va saqlash

Tasodifiy kalitlar (v4) indeksning yog’och bo’yicha qo’shimchalarni teng taqsimlaydi → «dumi» yo’q, lekin kesh lokalizmi yomonroq.
Vaqt boʻyicha saralanadigan (v7/ULID/Snowflake) «dumga» kiritiladi → eng yaxshi lokallik va siqish, lekin yuqori parallel yozuvdagi issiq sahifalar xavfi.

• prefikslar/tenant/region bo’yicha sharding (vaqtdan oldin 1-2 bayt qo’shish);
• interleaving: katta bitlardagi tasodifning bir qismi;
• batch-qo’shimchalar, B-yog’ochdagi fillfactor, BRINga o’tish/katta loglar uchun klaster.

• ’UUID (16B)’ vs’BIGINT (8B) ’/’ INT8’xotirani/keshni tejaydi; Base32/58/64 satrlari o’lchamni 20-60% ga oshiradi. DB uchun ikkilanib saqlang, chetidagi qatorga seriyalashtiring.

6) Xavfsizlik va maxfiylik

SEQUENCE/INT’dan URL/API’da ommaviy ID sifatida foydalanmang: taxmin qilinadigan → manbalar roʻyxati.
Tashqi havolalar uchun random, oldindan aytib boʻlmaydigan ID (v4/v7/ULID/KSUID) larni qoʻshing.
PIIni IDga kodlamang. Agar siz atributni yoqishingiz kerak boʻlsa, uni shifrlang/imzolang (masalan, JWE/JWS) yoki shaffof boʻlmagan tokenlardan foydalaning.
URL xavfsiz kodlash: Base32 Crockford, Base58 (’0OIl’dan tashqari), Base64url.

7) Ko’p tenantlik, prefikslar va yo’nalishlar

Formati:’[TENANT _ PREFIX] - [ID]’yoki binar:’tenant _ id | | id’.
Afzalliklari: ijarachi bo’yicha tezkor filtrlar/partiyalar, N + 1 skanerdan himoya qilish.
Salbiy tomonlari: katta bitlarda entropiya zichligi yomonlashishi mumkin → taqsimotni o’ylab ko’ring (hesh prefiks).
Hash qoʻshimchasi (2-3 bayt) qarama-qarshiliklarni kamaytiradi va shard-routingga yordam beradi:’shard = hash (id)% N’.

8) Tanlash bo’yicha amaliy tavsiyalar

API, ommaviy havolalar, qatʼiy tartibsiz taqsimlangan servislar: UUIDv4, ULID/KSUID.
Ko’pincha vaqt bo’yicha saralanadigan loglar/hodisalar/buyurtmalar: UUIDv7 yoki ULID (monoton).
Lokal monotonligi va qisqa kalitli ultra yuqori ruxsatnoma: Snowflake kabi 64-bit (vaqt intizomi talab qilinadi).
Artefaktlar/bildlar/bloblar omborxonalari: manzilli kontent (SHA-256), ustiga esa - insonparvar qisqa «vitrin» (Hashids/havola).
Bitta DBdagi lokal jadvallar: SEQUENCE/IDENTITY + ochiq havolalar uchun tashqi «oʻrash» (masking).

9) Amalga oshirish va misollar

9. 1 PostgreSQL

UUIDni binar holda saqlang, indekslar -’btree’yoki’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 (atomar hisoblagichlar/monutoniya)

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

9. 3 Snowflake oʻxshash generator (psevdokod)

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 ilovalarda

Go

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())

Node. js

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

Python

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

10) Kodlash va taqdimnomalar

• Base32 Crockford (ULID): registrga sezgisiz, vizual oʻxshash belgilarsiz.
• Base58: qisqacha Base32/64 o’qiladigan tokenlar uchun URL-safe.
• Base64url: qisqa, lekin’-’va’_’URLda.

Satrlarni solishtirishda dublikatlardan qochish uchun harf va formatni (defislar/ularning yoʻqligi) barqarorlashtiring.

11) Test-pleybuklar va kuzatuvchanlik

To’qnashuvlar:’id _ collision _ total’metrikasi (0 bo’lishi kerak),> 0 da alert.
Prefikslarni taqsimlash: katta baytlarning gistogrammasi - sotib olishni qidirmoqdamiz.
Ishlab chiqarish tezligi:’ids _ per _ sec’, p99 latentlik generator.
Clock skew (Snowflake uchun): tugunlar ofseti, «clock went back» hodisalari.
Indeks qoldiqlari: p95/p99’INSERT’latency; blokirovka/issiq sahifalar ulushi.

• Injekt «clock drift/back» → generator kutayotganiga ishonch hosil qiling.
• ’Sequence’ ning millisekundda toʻlishi → Kutishni tekshirish next_ms.
• Ommaviy parallellik → indeksda blokirovka boʻronlari yoʻq.

12) Anti-patternlar

Ommaviy ID sifatida AUTO_INCREMENT/SEQUENCE: taxmin qilinmoqda, sizib chiqmoqda. Ichki identifikatorning oshkora shaffof boʻlmagan identifikatoridan foydalaning.
UUIDv1 (MAS/vaqt) tashqariga: maxfiylik.
Trillionlab yozuvlar uchun 64 bitli tasodifiy ID: haqiqiy qarama-qarshilik xavfi.
HA: SPOF va tor joysiz global «markaziy generator».
clock back himoyasiz Time-sorted IDs: dublikatlar/regress tartibi.
Ochiq versiya/prefikssiz turli ID formatlarini aralashtirish → Debag/migratsiyalarda xaos.
ID’ni turli registrlar/shakllarga ega satrlar sifatida saqlash → yashirin dublikatlar.

13) Joriy etish chek-varaqasi

• Domen talablari uchun v4/v7/ULID/KSUID/Snowflake/SEQ/hash formati tanlangan.
• Tartibga qo’yiladigan talablar aniqlandi (saralanishi kerakmi).
• Qarama-qarshiliklar ehtimoli baholandi (b bit, n avlod) va xavf chegarasi belgilandi.
• Kodlash ishlab chiqilgan (BD + odamni o’qiydigan vitrinada binar).
• time-sorted uchun - clock back himoyasi, sequence-limitlar va NTP/PTP intizomi.
• Ommaviy ID uchun - oldindan aytib bo’lmaydigan (random/ULID/KSUID), PII yo’qligi.
• O’ylangan shard-routing (hash (id)% N), ko’p tenant prefikslar.
• Kuzatish darajasi: qarama-qarshilik, taqsimot, kechikish, clock skew metrikasi.
• Sequence/yuqori raqobat/deraza uzunligini to’ldirish uchun test-keyslar.
• Format, versiya, davr, bitli belgilar hujjatlari va migratsiya rejasi.

14) FAQ

Q: Mikroservislar uchun «andoza» nimani tanlash kerak?
A: UUIDv7 yoki ULID: vaqt tartibliligi, ko’p entropiya, chekkada oddiy avlod. Tashqi API uchun - ULID/UUIDv4 ham.

Q: Sizga qisqa va o’qiladigan ID kerak.
A: ULID/KSUID yoki Base58-kodlash 128-bit tasodifiy/vaqtinchalik ID. Uzunlik va to’qnashuvlarni eslang.

Q: «Qisqa raqamli» ID qilish mumkinmi, lekin xavfsiz?
A: Ha: ichki SEQni saqlang va opaque tokenini (96-128 bit rand) yoki Xashidsni tuz bilan + imzo bilan bering.

Q: SEQ dan UUIDv7 ga qanday ko’chish mumkin?
A: Yangi’id _ new’(UUID) ustunini kiriting, dublyaj qiling, yangi ID’ga havolalarni e’lon qiling, keyin RK/tashqi kalitlarni o’zgartiring va eskisini o’chirib tashlang.

Q: Nega ULID qo’shimchalarim «issiq» bo’lib qoldi?
A: O’sib borayotgan kalitlarni bitta indeksga qo’ying. Katta bitlarni aralashtiring, batch qo’shimchalaridan foydalaning.

15) Yakunlar

Yaxshi ID - bu vazifa uchun to’g’ri xususiyatlar to’plami: etarlicha entropiya, oldindan aytib bo’ladigan saralash (agar kerak bo’lsa), xavfsiz oshkoralik va indekslardan sog’lom foydalanish. Soddalik va taqsimot uchun UUIDv4/ULID/UUIDv7/KSUID tanlang, Snowflake - zich monotoniya va qisqa kalitlar uchun (vaqt tartibi bo’yicha), ketma-ketlik - mahalliy jadvallar uchun, kontent xeshlari - artefaktlar uchun. Kuzatuv va testlarni belgilang va identifikatorlar kutilmagan hodisalar manbai bo’lib qolmaydi.