იდენტიფიკატორის თაობა

1) რატომ უნდა მივაქციოთ ყურადღება იდენტიფიკატორებს?

• უნიკალურობა და მასშტაბები (კონფლიქტები, ჰორიზონტალური ზრდა).
• ბრძანება და დალაგება (დროებითი კორელაცია, რეპლიკაცია, დედობა).
• შენახვის შესრულება (ინდექსები, ცხელი გვერდები, გასაღების ზომა).
• უსაფრთხოება (არაპროგნოზირებადი, გაჟონვა, გამოცნობა).
• იუზაბილიტი/ინტეგრაცია (მოკლე, URL safe, არ არის მგრძნობიარე რეესტრის მიმართ).

ID არჩევანი არის კომპრომისი ენტროპიას, შეკვეთას, სიგრძეს, თაობის სიჩქარეს და ექსპლუატაციას შორის.

2) ძირითადი მოთხოვნები და ტერმინები

უნიკალურობა: შეჯახების ალბათობა უნდა იყოს დაბალია, ვიდრე მისაღები რისკი.
ენტროპია: „რამდენი უბედური შემთხვევა“ შეიცავს ID (bit).
შეკვეთები (დროის დახარისხება/k-sortable): ლექსიკური დახარისხება და დროის დახარისხება.
მონოტონია: არამდგრადი თანმიმდევრობა კვანძის/ნაკადის შიგნით.
ჩაწერის ადგილმდებარეობა: რამდენად კონცენტრირებულია ახალი ჩანართი ინდექსის „კუდში“ (ცხელი გვერდების საშიშროება).
პროგნოზირება: შესაძლებელია თუ არა მეზობელი ID- ების გამოცნობა (მნიშვნელოვანია უსაფრთხოებისთვის/API).
სპექტაკლი: ორობითი/სტრიქონი, Base16/32/36/58/64, დეფისი, რეესტრი.

3) იდენტიფიკატორის ძირითადი ოჯახები

3. 1 UUID

v4 (random): 122 ბიტი ენტროპია. არაკეთილსინდისიერი, კარგია უსაფრთხოებისა და სიმარტივისთვის. მინუსი: ინდექსების „ქაოტიტი“ შემთხვევითი განაწილების გამო - რაც, თუმცა, თანაბრად აფართოებს დატვირთვას და ასუფთავებს „ცხელ გვერდებს“.
v1 (დრო + MAC): შეკვეთით, მაგრამ ატარებს MAC/დრო (კონფიდენციალურობა); ხშირად თავს არიდებენ.
v7 (დროულად): მილიწამური დრო + რანდომის ნაწილი. დიზაინი ლექსიკური დახარისხებისთვის დროულად და კარგი შეკუმშვა BD- ში. კომპრომისი: ინდექსის „ცხელი კუდი“ ჩნდება; მკურნალობენ შარდენის/პრეფიქსი/ინკრეტით.

რჩევები

გარე API- სთვის და შეკვეთის არასათანადო მოთხოვნებისთვის - v4.
ღონისძიების/მეტყველების BD და „დალაგებული“ გასაღებებისთვის - v7.

3. 2 ULID (Crockford Base32)

128 ბიტი: დროის 48 ბიტი (ms) + შემთხვევითი 80 ბიტი. ლექსიკოგრაფიულად დალაგებულია დროში, მეგობრული ადამიანი ('I, L, O, U'), URL safe. არსებობს ერთფეროვანი ცვალებადობა (იგივე დროის ნიშნით, შემთხვევითი ნაწილი იზრდება).
უპირატესობები: კითხვა, მოწესრიგება, ტოლერანტობა.
უარყოფითი: ჩანართების ძალიან მაღალი სიხშირით დროის ერთ მომენტში - „ცხელი კუდი“.

3. 3 KSUID

160 ბიტი: 32 დროის ბიტი (წმ) შედარებით + 128 ბიტი შემთხვევითი. უფრო დიდი დროის დიაპაზონი და სტაბილური განლაგება, ხაზები უფრო მოკლეა, ვიდრე ULID? (არა - უფრო გრძელი, მაგრამ კოდირებით), კარგია განაწილებული ლოგებისა და ობიექტებისთვის.

3. 4 Snowflake მსგავსი (k-sortable flake IDs)

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

თვისებები: ერთფეროვანი ზრდა კვანძზე, კვაზი გლობალური უნიკალურობა, მოკლე (64 ბიტი) ორობითი წარმოდგენა.
რისკები: დამოკიდებულება საათებზე (დროის დრიფტი/რეგრესია), ერთ ტიკაში ამოწურვა, რეგიონის/სამუშაო ბიტების კოორდინაცია.
მას მკურნალობენ: დაცვა „clock back“ - სგან, sequence რეზერვი, დროის დეტექტორი, PTP/NTP დისციპლინა.

3. 5 BD თანმიმდევრობა (SEQUENCE/IDENTY)

უმარტივესი ერთფეროვანი თაობა ერთ DBMS/shard- ში.
დადებითი: მოკლე, სწრაფი, მოსახერხებელი ადგილობრივი ცხრილებისთვის.
უარყოფითი: ძნელია გლობალურად განაწილებულ კლასტერში; პროგნოზირებადი (უსაფრთხოდ, როგორც საჯარო გასაღები), ქმნის ინდექსის ცხელ კუდს.

3. 6 შინაარსის მისამართის ID (hash შინაარსი)

SHA-256/Blake3 შინაარსიდან არის სტაბილური ID, დედუპლიკაცია, მთლიანობის შემოწმება, ქეშირება.
დადებითი: დეტერმინიზმი, ჩანაცვლებისგან დაცვა.
უარყოფითი მხარეები: ძვირადღირებული თაობა (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) ჩასმულია „კუდში“ - საუკეთესო ადგილმდებარეობა და კომპრესია, მაგრამ ცხელი გვერდების რისკი მაღალი პარალელური ჩანაწერის ქვეშ.

• პრეფიქსი/შარდინგი tenant/region (დაამატეთ 1-2 ბაიტი დროზე ადრე);
• interleaving: უბედური შემთხვევის ნაწილი მაღალ ბიტებში;
• Butch ჩანართები, fillfactor B- ხეში, ავტომატური გადაადგილება BRIN/კლასტერიზაციისთვის დიდი ლოგებისთვის.

• 'UUID (16B)' vs 'BIGINT (8B) '/' INT8 "დაზოგავს მეხსიერებას/ქეშს; Base32/58/64 ხაზები ზრდის ზომას 20-60% -ით. DD- სთვის შეინახეთ ორობითი, სერიები ხაზში ზღვარზე.

6) უსაფრთხოება და კონფიდენციალურობა

არ გამოიყენოთ SEQUENCE/INT, როგორც საჯარო პირადობის მოწმობა URL/API- ში: გამოიცანით რესურსების გადარიცხვა.
დაამატეთ რანდომიური, არაპროგნოზირებადი ID (v4/v7/ULID/KSUID) გარე ბმულებისთვის.
არ დაშიფროთ PII ID- ში. თუ თქვენ უნდა ჩართოთ ატრიბუტი - დაშიფვრა/ხელმოწერა (მაგალითად, JWE/JWS) ან გამოიყენეთ გაუმჭვირვალე ნიშნები.
UR- უსაფრთხო კოდები: Base32 Crockford, Base58 ('0OIl' გარეშე), Base64url.

7) მრავალ ტენანტობა, პრეფიქსი და მარშრუტიზაცია

ფორმატი: '[TENANT _ PREFIX] - [ID] "ან ორობითი:' tenant _ id | | id '.
უპირატესობები: სწრაფი ფილტრები/ქირაობა, დაცვა N + 1 სკანირებისგან.
უარყოფითი მხარეები: შეიძლება გაუარესდეს ენტროპიის სიმკვრივე მაღალ ბიტებში - იფიქრეთ განაწილებაზე (პრეფიქსი ჰაში).
Hash-suffix (2-3 ბაიტი) ამცირებს კონფლიქტს და ეხმარება shard routing- ს: 'shard = hash (id)% N'.

8) პრაქტიკული რეკომენდაციები არჩევანის გაკეთებასთან დაკავშირებით

API, საზოგადოებრივი ბმულები, განაწილებული სერვისები მკაცრი წესრიგის გარეშე: UUIDv4, ULID/KSUID.
ლოგოები/მოვლენები/შეკვეთები, სადაც ხშირად ვიყენებთ დროს: UUIDv7 ან ULID (ერთფეროვანი).
ულტრა მაღალი გამშვები ადგილობრივი ერთფეროვნებით და მოკლე გასაღებით: Snowflake მსგავსი 64 ბიტი (საჭიროა დროის დისციპლინა).
არტეფაქტების/ბილეთების/ბლოების საცავი: შინაარსის მისამართები (SHA-256), ხოლო თავზე - მეგობრული მოკლე „ვიტრინა“ (Hashids/ბმული).
ადგილობრივი ცხრილი ერთ მონაცემთა ბაზაში: SEQUENCE/IDENTITY + გარე „შეფუთვა“ საჯარო ბმულებისთვის (masking).

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 (ატომური მრიცხველები/Monutonia)

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

9. 3 Snowflake მსგავსი გენერატორი (ფსევდო კოდი)

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

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) კოდირება და წარმოდგენა

• Base32 Crockford (ULID): არ არის მგრძნობიარე რეესტრში, ვიზუალურად მსგავსი სიმბოლოების გარეშე.
• Base58: უფრო მოკლეა ვიდრე Base32/64 ადამიანური ნიშნებისთვის, URL safe.
• Base64url: მოკლედ, მაგრამ '-' და '_' URL- ში.

შეამოწმეთ რეესტრი და ფორმატი (დეფისი/მათი არარსებობა), რათა თავიდან აიცილოთ დუბლიკატები ხაზების შედარების დროს.

11) ტესტის ფლეიბუკები და დაკვირვება

კონფლიქტები: მეტრიკა 'id _ collision _ total' (უნდა იყოს 0), ალერტი> 0.
პრეფიქსების განაწილება: უფროსი ბაიტის ჰისტოგრამა - ვეძებთ შეძენას.
თაობის სიჩქარე: 'idds _ per _ sec', გენერატორის ლატენტობა.
Clock skew (Snowflake- ისთვის): კვანძების ოფსეტი, „clock went back“ - ის მოვლენები.
ინდექსის კუდები: p95/p99 'INSERT' latency; ბლოკირების/ცხელი გვერდების წილი.

• ინჟექტორი „clock drift/back“ დარწმუნებული ვართ, რომ გენერატორი ელოდება/გადართვას.
• გადატვირთვა 'sequence' მილიწამში - შემდეგი _ ms მოლოდინის შემოწმება.
• მასობრივი პარალელიზმი - არის თუ არა ქარიშხლის დაბლოკვა ინდექსში.

12) ანტი შაბლონები

AUTO _ INCREMENT/SEQUENCE, როგორც საჯარო პირადობის მოწმობა: გამოიცანით, გაჟონვა. გამოიყენეთ საზოგადოებრივი გაუმჭვირვალე ID შიდა თავზე.
UUIDv1 (IAU/დრო) გარეთ: კონფიდენციალურობა.
64 ბიტიანი შემთხვევითი ID ჩანაწერების ტრილიონებზე: კონფლიქტების რეალური რისკი.
გლობალური „ცენტრალური გენერატორი“ HA გარეშე: SPOF და ვიწრო ადგილი.
Time-sorted IDs clock back- ისგან დაცვის გარეშე: დუბლიკატები/წესრიგის რეგრესია.
სხვადასხვა ID ფორმატის შერევა აშკარა ვერსიის/პრეფიქსი-ქაოსის გარეშე დებაგში/მიგრაციაში.
ID- ის, როგორც ხაზების, სხვადასხვა რეგისტრაციით/ფორმებით შენახვა არის ფარული დუბლიკატები.

13) განხორციელების შემოწმების სია

• შეირჩა ფორმატი (v4/v7/ULID/KSUID/Snowflake/SEQ/hash) დომენის მოთხოვნით.
• განსაზღვრულია წესრიგის მოთხოვნები (საჭიროა თუ არა ტრანსპორტირება).
• შეფასებულია შეჯახების ალბათობა (b bit, n თაობები) და დადგენილია რისკის ზღვარი.
• დაშიფვრა შექმნილია (ორობითი BD + ადამიანური ვიტრინა).
• time-sorted- ისთვის - დაცვა clock back, sequence-limites და NTP/PTP დისციპლინისგან.
• საზოგადოებრივი ID- სთვის - არაპროგნოზირებადი (რანგი/ULID/KSUID), PII- ის არარსებობა.
• გააზრებული იყო შარდ-როუტინგი (hash (id)% N), მრავალ ჩრდილოვანი პრეფიქსი.
• დაკვირვება: შეჯახების მეტრიკა, განაწილება, შეფერხება, წებოვანი ციკლი.
• ტესტის შემთხვევები sequence/მაღალი კონკურენცია/ფანჯრის სიგრძე.
• ფორმატის, ვერსიის, ეპოქის, ბიტის მარკირების დოკუმენტაცია და მიგრაციის გეგმა.

14) FAQ

Q: რა უნდა აირჩიოთ „ნაგულისხმევი“ მიკრო სერვისებისთვის?
A: UUIDv7 ან ULID: დროის წესრიგი, ბევრი ენტროპია, მარტივი თაობა ზღვარზე. გარე API- სთვის - ULID/UUIDv4 ასევე კარგი.

Q: გჭირდებათ მოკლე და ადამიანური ID.
A: ULID/KSUID ან Base58 კოდირება 128 ბიტიანი შემთხვევითი/დროებითი ID. გახსოვდეთ სიგრძე და კონფლიქტი.

Q: შესაძლებელია „მოკლე რიცხვების“ ID გაკეთება, მაგრამ უსაფრთხოა?
A: დიახ: შეინახეთ შიდა SEQ, და გარედან მიეცით opaque ნიშანი (რანგი 96-128 ბიტი) ან Hashids მარილით + ხელმოწერა.

Q: როგორ გადავიდეთ SEQ- დან UUIDv7- ზე?
A: შეიყვანეთ ახალი სვეტი 'id _ new' (UUID), გაატარეთ, გამოაქვეყნეთ ბმულები ახალ ID- ზე, შემდეგ შეცვალეთ RK/გარე გასაღებები და წაშალეთ ძველი.

Q: რატომ გახდა ჩემი ULID ჩანართები ცხელი?
A: ჩასვით მკაცრად მზარდი გასაღებები ერთ ინდექსში. დაარბიეთ წვეულებები/ტენანტი, აურიეთ უფროსი ბიტები, გამოიყენეთ batch ჩანართები.

15) შედეგები

კარგი ID არის ამოცანისთვის თვისებების სწორი ნაკრები: საკმარისია ენტროპია, პროგნოზირებადი დახარისხება (საჭიროების შემთხვევაში), უსაფრთხო საჯაროობა და ინდექსების ჯანსაღი მოქმედება. შეარჩიეთ UUIDv4/ULID/UUIDv7/KSUID სიმარტივისა და განაწილებისთვის, Snowflake - მკვრივი მონოტონიისა და მოკლე გასაღებებისთვის (დროის დისციპლინით), თანმიმდევრობით - ადგილობრივი ცხრილებისთვის, შინაარსის ჰეშისთვის - არტეფაქტებისთვის. განათავსეთ დაკვირვება და ტესტები - და იდენტიფიკატორები შეწყვეტენ სიურპრიზების წყაროს.