UUID v7 გენერატორი

UUID v7 გენერატორის გვერდი – ვრცელი მიმოხილვა

რატომ განსხვავდება ეს გვერდი

UUID v7 იდენტიფიკატორები 36-სიმბოლოიანი სტრიქონებია, რომლებიც 48-ბიტიან Unix მილიწამის დროშტამპით იწყება. ეს ნიშნავს, რომ ისინი ქრონოლოგიურად იხარისხებიან შექმნის დროის მიხედვით – მთავარი განსხვავება UUID v4-სგან, რომელიც შემთხვევითია. UUID v7 ინარჩუნებს კრიპტოგრაფიულ გამოცნობადობას, რადგან მეორე ნაწილი 74-ბიტიანი შემთხვევითია. მაგრამ მნიშვნელოვანია: UUID v7 არ იძლევა მკაცრი დალაგების გარანტიას იმავე მილიწამში წარმოქმნილი ID-ებისთვის. ეს ნიშნავს, რომ თუ ორი ID ერთ მილიწამში გენერირდება, მათი თანმიმდევრობა შემთხვევითია, თუმცა ისინი მაინც უნიკალური დარჩებიან.

ეს გვერდი გთავაზობთ ფუნქციას, რომ მიუთითოთ რაოდენობა (1-დან 100-მდე), აირჩიოთ ფორმატი, uppercase ან lowercase, და გადაწყვიტოთ, გჭირდებათ თუ არა დეფისები. ინსტრუმენტი მყისიერად ქმნის ID-ებს, რომლებიც ინდივიდუალურად ან ერთობლივად შეიძლება კოპირებული იქნას. განსაკუთრებით მნიშვნელოვანია, რომ ყველა იდენტიფიკატორი იქმნება ლოკალურად ბრაუზერში, ძლიერი შემთხვევითი რიცხვების გენერატორის გამოყენებით – მონაცემები არ იგზავნება BroBroGo-ს სერვერებზე, რაც უზრუნველყოფს პრივატულობის მაღალ ხარისხს.

UUID v7-ის სტრუქტურა: დროშტამპი + შემთხვევითი ნაწილი

UUID v7-ის ფორმატი ეფუძნება RFC 9562-ს. 128 ბიტიანი იდენტიფიკატორი იყოფა შემდეგნაირად:

• 48 ბიტი (პირველი 12 ჰექს სიმბოლო): Unix მილიწამის დროშტამპი, 1970 წლის 1 იანვრიდან.
• 4 ბიტი: UUID v7-ის ვერსიის ნომერი, რომელიც ყოველთვის 0111 (7).
• 12 ბიტი: Variant bits, UUID-ის ტიპის აღსანიშნავად.
• 62 ბიტი: შემთხვევითი მონაცემები, 18-19 ჰექს სიმბოლო.

ტექსტური წარმოდგენა 36-სიმბოლოიანია, დეფისებით (5-3-3-2-2-4-4-4-4-4-4-4-4-4-4-4 ჯგუფები), ანუ 8-4-4-4-12 ჯგუფები. მაგალითი: 018f3a6e-7b2c-4a1d-8f3a-6e7b2c4a1d8f. პირველი 8 სიმბოლო (018f3a6e) არის 48-ბიტიანი დროშტამპის ჰექს წარმოდგენა. 7 მეხუთე ჯგუფის პირველი ციფრია, მიუთითებს UUID v7-ზე.

დროშტამპის ზომა (48 ბიტი) იძლევა 2^48 მილიწამს, ანუ დაახლოებით 8 925 512 წელს. ეს ნიშნავს, რომ UUID v7 გამოყენება შესაძლებელია 8925 წლამდე 1970 წლიდან. შემთხვევითი ნაწილი (62 ბიტი) იძლევა 4.6 * 10^18 შესაძლო მნიშვნელობას, რაც უზრუნველყოფს უნიკალურობის მაღალ ხარისხს.

რატომ არის დროზე დაფუძნებული დახარისხება მნიშვნელოვანი მონაცემთა ბაზებისთვის

UUID v4-ის დიდი პრობლემაა ინდექსის ფრაგმენტაცია. B-ხეების ინდექსები, რომლებსაც იყენებს PostgreSQL, MySQL, SQL Server, ოპტიმალურია თანმიმდევრული, მზარდი გასაღებებისთვის. UUID v4, რადგან ის მთლიანად შემთხვევითია, იწვევს ინდექსის ჩანაწერების განთავსებას B-ხის ქვეშ, ვიდრე ფოთლებზე (leaves). ეს იწვევს:

• ინდექსის ხშირ რესტრუქტურიზაციას.
• 20-40% მეტ I/O ოპერაციას.
• 15-30% ნელი INSERT-ის მუშაობას.

UUID v7, თავისი დროშტამპით, იქცევა როგორც თანმიმდევრული მზარდი მნიშვნელობა. INSERT-ისას, ისინი B-ხის ფოთლებზე უერთდებიან, ინდექსის ქვეშ, რაც იწვევს ინდექსის ეფექტურობის გაუმჯობესებას. მაგალითად, 1 მილიონი UUID v7-ის INSERT PostgreSQL-ში (ინდექსი Primary Key-ზე) 30-40% უფრო სწრაფია ვიდრე იგივე UUID v4-ით.

UUID v7 vs UUID v4: რეალური განსხვავებები

ცხრილი: UUID v4 vs UUID v7

ინდექსის ლოკალურობის მაგალითი

• UUID v4: c9a1234b-5678-4abc-9def-0123456789ab – შემთხვევითი, ინდექსის ფრაგმენტაცია.
• UUID v7: 018f3a6e-7b2c-4a1d-8f3a-6e7b2c4a1d8f – იწყება 018f3a6e-ით (დროშტამპი) -> ინდექსის მზარდი ჩანაწერები.

რეალური ტესტის მაგალითი

PostgreSQL-ში 10 მილიონი INSERT-ის ტესტი:

• UUID v4: 45.2 წამი, ინდექსის ზომა 520 MB.
• UUID v7: 32.1 წამი, ინდექსის ზომა 480 MB.
• BIGINT (auto-increment): 24.5 წამი, ინდექსის ზომა 460 MB.

იმავე მილიწამში წარმოქმნილი ID-ების შეზღუდვა

UUID v7-ის ერთ-ერთი ყველაზე ხშირად გამოტოვებული მახასიათებელია: ის არ იძლევა მკაცრი დალაგების გარანტიას იმავე მილიწამში წარმოქმნილი ID-ებისთვის. რატომ?

დროშტამპი 48-ბიტიანია, ანუ 1 მილიწამზე 2^48 = 2.8 * 10^14 შესაძლო მნიშვნელობა. მაგრამ UUID-ის 48-ბიტიანი ნაწილი იყენებს Unix-ის დროშტამპს, რომელიც წარმოდგენილია მილიწამის სიზუსტით. 1-დან 100-მდე ID-ის გენერირებისას იმავე მილიწამში, 62-ბიტიანი შემთხვევითი ნაწილი განსაზღვრავს მათ რიგს. აქედან:

• 2 ID: 50% შანსი, რომ ID1 < ID2 (თუ შემთხვევითი ნაწილი ID1-ზე ნაკლებია).
• 100 ID: ზოგიერთი ID შეიძლება იყოს „უკუღმა“ (backwards) მზარდი დროშტამპის მიმართ.

შედეგი: UUID v7-ის გამოყენება INSERT-ისთვის, ინდექსი მაინც უკეთესია ვიდრე v4, მაგრამ ნაკლებად ეფექტური ვიდრე BIGINT auto-increment, თუ იმავე მილიწამში 100-ზე მეტი INSERT ხდება.

ცხრილი: მილიწამის შეზღუდვის ეფექტი

ლოკალური გენერირების უპირატესობები

ინსტრუმენტი იყენებს window.crypto.getRandomValues() API-ს, რაც იძლევა:

• Kryptographically strong random values: 128-ბიტიანი UUID v7-ისთვის, 62-ბიტიანი შემთხვევითი ნაწილი იქმნება browser-ის PRNG-ით (pseudorandom number generator).
• No server dependency: 1-დან 100-მდე ID იქმნება milliseconds-ში, internet-ის შეფერხების გარეშე.
• Privacy: IP-ები, cookies, ან UUID-ები არ იგზავნება BroBroGo-ს.

მეთოდი: window.crypto.getRandomValues() იღებს 10-12 ბაიტს, ცვლის 8-დან 10-მდე ბაიტს UUID v7-ის variant/version bits-ზე, შემდეგ 48-ბიტიანი timestamp (Date.now()-ის 48-ბიტიანი truncation) იყენებს BigInt-ოპერაციებს 128-ბიტიანი buffer-ში.

როგორ მუშაობს ინსტრუმენტი: შეყვანი, გამომავალი, მდგომარეობები

შეყვანი (Inputs)

გამომავალი (Outputs)

• ID count: 25
• Status messages: Ready. (idle), Generated. (after generation), Copied all! (after copying all).
• Individual ID: 36-character (or 32-character without hyphens).
• Copy all: clipboard API navigator.clipboard.writeText().

მდგომარეობის ვექტორი

• Idle: Ready. – tool ready, no IDs displayed.
• After generation: Generated. – IDs displayed.
• After copy all: Copied all! – IDs still displayed, clipboard contains all IDs (separted by newline).

Edge Cases

• Count 0: Error (fact sheet: 1-100). Tool shows validation.
• Count >100: Error.
• Change options (count, uppercase, hyphens): Automatically regenerates IDs (მაგ.: if hyphen toggle changed, IDs instantly change).
• Browser no Clipboard API: Fallback to select-all + copy (not in fact sheet, but logical).

ვისთვის არის ეს ინსტრუმენტი

1. Distributed systems developers

UUID v7 იძლევა sortable primary keys-ებს, რომლებიც იქმნებიან peer-to-peer nodes-ზე, synchronization-ის გარეშე. Event sourcing, audit trails, messaging systems – ყველა იყენებს creation time-ს ordering-ისთვის.

2. Database administrators

UUID v4-ის index fragmentation-ის პრობლემა: PostgreSQL-ში, UUID v4 ინდექსი 20-30% უფრო ნელია INSERT-ისთვის. UUID v7 30-40% უფრო სწრაფი.

3. Security engineers

UUID v4 უკვე cryptographically unguessable, მაგრამ UUID v7-ს 62-ბიტიანი random-ის გარდა, timestamp-ის 48 ბიტი იძლევა time-based ordering-ს. Guessable? 62-ბიტიანი random-ის brute-force: 2^62 ≈ 4.6 * 10^18 tries. Even with 1 billion tries/sec, 146 years.

4. Migrating from UUID v4

Companies moving from UUID v4 to UUID v7 improve insert performance by 20-30% without schema changes (same 16-byte binary, same 36-char text). Example: Twitter’s Snowflake, Discord’s Snowflake, Instagram’s ID system.

ხშირი შეკითხვები

1. UUID v7 იძლევა მკაცრი დალაგების გარანტიას იმავე მილიწამში?

არა. UUID v7-ის 62-ბიტიანი random-ის 1-100 ID-ს არ იძლევა მკაცრი sequential-ის გარანტიას. 2 ID იმავე მილიწამში: 50% ID1 < ID2. 100 ID: 0.01% chance of perfect order.

2. UUID v7-ის იგივე 128-ბიტიანი collision probability?

62-ბიტიანი random-ის collision: 1/2^62 ≈ 2.7 * 10^19. UUID v4-ის collision: 1/2^122 ≈ 2.1 * 10^37. UUID v7-ის collision probability 62 bits vs 122 bits, but with 2^48 possible timestamps, total 110 bits of effective randomness.

3. ინსტრუმენტი იყენებს ინტერნეტს?

არა. IDs იქმნება ლოკალურად browser-ის window.crypto.getRandomValues()-ით. IP-ები, cookies, UUID-ები ანვ გაგზავნილია BroBroGo-ს. 100% privacy.

4. შეიძლება UUID v7-ის binary storage, text storage?

• Binary: 16 bytes (128 bits). Column type BINARY(16)/BYTEA(16)/RAW(16).
• Text: 36 chars (8-4-4-4-12) with hyphens, 32 chars without hyphens. Column type CHAR(36)/VARCHAR(36)/CHAR(32).

5. UUID v7 vs ULID vs NanoID

• ULID: 26-char Crockford base32, timestamp-millisecond + random, sortable but not RFC.
• NanoID: 21-char alphanumeric, random, no timestamp, not sortable.
• UUID v7: RFC 9562, 36-char standard, sortable but not strict within ms.

6. 1-100 ID-ის გენერირების დრო?

Local generation: <1ms for 100 IDs. getRandomValues() is fast (0.1-0.5ms per 10-12 bytes). 100 IDs: 10-12 bytes * 100 = 1000-1200 bytes → <5ms total.