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

დააგენერირეთ UUID v4 მნიშვნელობები ონლაინ: 122 შემთხვევითი ბიტი, სტანდარტული UUID ფორმა და კოპირებისთვის მზა შედეგები პირდაპირ ბრაუზერში.

ფორმატი
გენერირებული ID-ები
მზადაა. დააგენერირეთ UUID v4 მნიშვნელობები თქვენს ბრაუზერში.

როგორ იქმნება ეს ID

სტრუქტურა
128-ბიტიანი UUID მე-4 ვერსიითა და RFC ვარიანტის ბიტებით, ნაჩვენები როგორც 8-4-4-4-12 თექვსმეტობითი ჯგუფები.
ენტროპია
122 შემთხვევითი ბიტი crypto.randomUUID() ფუნქციიდან.
დრო
არ აქვს; v4 ID-ები არ ამჟღავნებს მათი შექმნის დროს.
კოლიზიის რისკი
კოლიზიები რეგულირდება 122 შემთხვევითი ბიტით, რაც ბევრად აღემატება ნორმალური სისტემების პრაქტიკულ მოცულობებს.
მაგალითი
6855dd6e-dc7f-42e8-9cc4-9ea439da9be1

თქვენი ID-ები გენერირდება ლოკალურად ბრაუზერის ძლიერი შემთხვევითობის გამოყენებით. BroBroGo-ზე არაფერი იგზავნება.

ხშირად დასმული კითხვები

როდის უნდა გამოვიყენო UUID v4?

გამოიყენეთ UUID v4, როდესაც გჭირდებათ გაუმჭვირვალე შემთხვევითი იდენტიფიკატორები, რომლებიც არ სორტირდება შექმნის დროის მიხედვით და არ ამჟღავნებს დროის ინფორმაციას.

შემიძლია წავშალო დეფისები ან გამოვიყენო დიდი ასოები?

დიახ. UUID v4 ინსტრუმენტი ინარჩუნებს პარამეტრების პანელს, ასე რომ თქვენ შეგიძლიათ ჩართოთ/გამორთოთ დეფისები და დიდი ასოები.

UUID v4 გენერატორი: 122 ბიტი შემთხვევითობა, 36 სიმბოლო და ნულოვანი კოლიზიის რისკი

UUID v4 გენერატორის გვერდი ქმნის ერთ ან მეტ UUID v4 იდენტიფიკატორს — 36-სიმბოლოიან, შემთხვევით სტრიქონს, რომელიც ჩაწერილია სტანდარტული 8-4-4-4-12 ჰექს ფორმატში. მომხმარებელი აკონტროლებს რაოდენობას (1-დან 100-მდე), ასოების რეგისტრს (uppercase) და დეფისების ჩართვას. იდენტიფიკატორები მყისიერად ჩნდება ბრაუზერში, ხოლო ერთზე დაჭერით მისი კოპირება შეიძლება, ან ყველა ერთდროულად — ღილაკით "Copy all".

რა ხდის ამ გვერდს განსხვავებულს

UUID v4 იყენებს 122 ბიტ სუფთა შემთხვევითობას თითოეული იდენტიფიკატორისთვის. დარჩენილი 6 ბიტი ფიქსირებულია: 4 ბიტი ვერსიისთვის (აღნიშნავს v4-ს) და 2 ბიტი ვარიანტისთვის (RFC 4122-ის მიხედვით). ეს ნიშნავს, რომ 122 ბიტიდან თითოეულს აქვს 50% შანსი იყოს 0 ან 1, რაც ქმნის 2^122 ≈ 5.3 × 10^36 შესაძლო UUID v4 მნიშვნელობას.

ამ იდენტიფიკატორებს არ გააჩნიათ დროითი ან რიგითობის ინფორმაცია. UUID v4 მნიშვნელობები დალაგებულია შემთხვევით — ისინი არ ასახავს შექმნის თანმიმდევრობას. ეს ქმნის სერიოზულ შედეგებს მონაცემთა ბაზის დიზაინში: როცა UUID v4 გამოიყენება როგორც პირველადი გასაღები (primary key), B-tree ინდექსი ფრაგმენტირებული ხდება. მიზეზი ისაა, რომ ახალი ჩანაწერის ჩასმისას მისი UUID v4 არ ჯდება ინდექსის ბოლოში, არამედ ხვდება სადმე შუაში, რაც აიძულებს ინდექსის ხეების რეორგანიზაციას. დროზე დაფუძნებული UUID ფორმატები (როგორიცაა UUID v7) ამ პრობლემას გაურბიან.

კოლიზიის ალბათობა — ორი იდენტური UUID v4-ის შექმნა — პრაქტიკულად უმნიშვნელოა. 122 ბიტი შემთხვევითობის გათვალისწინებით, 1 მილიარდი UUID v4-ის გენერირების შემდეგაც კი, კოლიზიის ალბათობა რჩება 10^-18-ზე ნაკლები. ეს ნიშნავს, რომ თეორიულადაც კი, ასეთი მოვლენა პრაქტიკაში მხოლოდ მაშინ მოხდება, თუ ყოველ წამში 1 მილიარდი UUID-ს გენერირებთ მილიარდობით წლის განმავლობაში.

გვერდი გვთავაზობს ფორმატის სპეციფიკურ გადამრთველებს (uppercase, hyphens), რომლებიც მხოლოდ UUID v4-სა და UUID v7-ს ეხება. სხვა ID ტიპები (ULID, NanoID) იყენებენ განსხვავებულ კონტროლს.

UUID v4-ის სტრუქტურა: 122 ბიტი, 6 ფიქსირებული ბიტი

UUID v4-ის ფორმატი განსაზღვრულია RFC 4122-ით. სტანდარტული 36-სიმბოლოიანი წარმოდგენა იყენებს 32 ჰექს სიმბოლოს (0-9, a-f) და 4 დეფისს:

xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx

სადაც:

  • 4 — ვერსიის ბიტი: მე-13 ჰექს ციფრი (თუ ვთვლით 0-დან) ყოველთვის 4-ია. ეს ნიშნავს, რომ 4 ბიტი (0100) ფიქსირებულია.
  • y — ვარიანტის ბიტი: მე-17 ჰექს ციფრი. RFC 4122-ის მიხედვით, ეს მნიშვნელობა ყოველთვის 8, 9, a ან b-ია. ეს 2 ბიტი (10xx) ფიქსირებულია.

დანარჩენი 122 ბიტი (30.5 ჰექს ციფრი) მთლიანად შემთხვევითია. ეს მიიღწევა crypto.getRandomValues() API-ს გამოყენებით ბრაუზერში, რაც უზრუნველყოფს კრიპტოგრაფიულად ძლიერ შემთხვევითობას.

თუ დეფისები გამოტოვებულია, UUID v4 ხდება 32-სიმბოლოიანი ჰექს სტრიქონი: xxxxxxxxxxxx4xxyxxxxxxxxxxxxxxx. ეს ფორმატი ნაკლებად იკითხება, მაგრამ უფრო კომპაქტურია URL-ებში ან API-ებში.

Uppercase toggle-ის ჩართვისას, ჰექს ასოები a-f იცვლება A-F-ით. ეს გავლენას ახდენს მხოლოდ ვიზუალურ წარმოდგენაზე — იდენტური 122-ბიტიანი მნიშვნელობა იწერება სხვა რეგისტრში. თუმცა, თუ UUID v4 გამოიყენება API-ში, uppercase-ის გამოყენება შეიძლება იყოს არათანმიმდევრული, თუ სისტემა მოელის lowercase-ს. RFC 4122-ის მიხედვით, UUID-ები ჩვეულებრივ იწერება lowercase-ში, მაგრამ ბევრი სისტემა იღებს ორივე რეგისტრს.

ფორმატის კონფიგურაცია: count, uppercase, hyphens

Count — მთელი რიცხვი 1-დან 100-მდე. ყოველ 100 UUID v4-ს აქვს 100 × 122 = 12,200 ბიტი შემთხვევითობა. თუ count-ი 100-ზე ნაკლებია, გენერირებული იდენტიფიკატორების რაოდენობა მითითებულზე ნაკლებია. 100-ზე მეტი count-ი დაუშვებელია, მაგრამ მომხმარებელს შეუძლია გაიმეოროს გენერაცია რამდენჯერმე.

Uppercase toggle — თუ ჩართულია, ყველა ჰექს ასო (a, b, c, d, e, f) გამოისახება როგორც A, B, C, D, E, F. ეს გავლენას ახდენს მხოლოდ ვიზუალურ წარმოდგენაზე, მაგრამ მნიშვნელოვანია ინტეროპერაბელურობისთვის: ზოგიერთი სისტემა (მაგ., PostgreSQL) ინახავს UUID-ებს როგორც 128-ბიტიან მთელ რიცხვს, ამიტომ lowercase/uppercase-ს მნიშვნელობა არ აქვს; თუმცა, თუ UUID-ები ინახება როგორც ტექსტური სტრიქონები, ზოგიერთმა ტექსტურმა ინდექსმა შეიძლება გაანასხვაოს "a" და "A".

Include hyphens toggle — თუ გამორთულია, დეფისები (-----) ამოღებულია, ხოლო UUID v4 ხდება 32-სიმბოლოიანი ჰექს სტრიქონი. ეს ფორმატი გამოიყენება URL-ებში, API-ების endpoint-ებში ან გარკვეულ სისტემებში, სადაც 36-სიმბოლოიანი ფორმატი ზედმეტია. თუმცა, 32-სიმბოლოიანი ფორმატის წაკითხვა რთულია, ხოლო 122-ბიტიანი მნიშვნელობა იგივე რჩება.

ყველა ამ პარამეტრის ცვლილება (count, uppercase, hyphens) მყისიერად იწვევს ყველა იდენტიფიკატორის რეგენერაციას. მაგალითად, თუ თავიდან 50 UUID v4-ს ქმნით lowercase-ში, შემდეგ uppercase-ზე გადასვლისას 50 ახალი UUID v4-ის გენერირება მოხდება — ისინი არ იქნება იგივე, რაც ადრე იყო lowercase-ში.

UUID v4-ის გავლენა მონაცემთა ბაზის ინდექსებზე

ეს არის UUID v4-ის ყველაზე ნაკლებად განხილული, მაგრამ პრაქტიკულად ყველაზე მნიშვნელოვანი ასპექტი. B-tree ინდექსები, რომლებიც გამოიყენება MySQL, PostgreSQL, Oracle და SQL Server-ში, ოპტიმიზირებულია სერიული ჩასმისთვის (sequential inserts). თუ პირველადი გასაღები (primary key) იზრდება მონოტონურად (როგორიცაა auto-increment მთელი რიცხვი ან UUID v7), ახალი ჩანაწერები ყოველთვის ემატება B-tree-ის მარჯვენა მხარეს, რაც ინდექსის რეორგანიზაციას იშვიათს ხდის.

UUID v4-ის შემთხვევაში, ახალი იდენტიფიკატორები ნაწილდება 2^122-ის მთელ სივრცეში. B-tree-ში, ეს იწვევს ინდექსის ფრაგმენტაციას: ინდექსის ხეები იყოფა, იქმნება ცარიელი გვერდები, და ჩასმის ოპერაცია ნელდება. ეს განსაკუთრებით მნიშვნელოვანია იმ სისტემებში, სადაც ბევრი ჩაწერაა (write-heavy). PostgreSQL-ისა და MySQL-ის InnoDB-ის ტესტებმა აჩვენა, რომ UUID v4-ის გამოყენებამ B-tree ინდექსზე შეიძლება გამოიწვიოს ჩასმის სიჩქარის 20-40%-იანი შენელება, ვიდრე sequential key-ით.

ამის გამოსასწორებლად, შემოთავაზებულია:

  • UUID v7: 48-ბიტიანი timestamp, 74-ბიტიანი random
  • ULID: 48-ბიტიანი timestamp, 80-ბიტიანი random
  • Sequential UUID-ები (UUID v1, v6)

თუმცა, UUID v4 მაინც ფართოდ გამოიყენება იმ სისტემებში, სადაც თანმიმდევრობის არარსებობა უპირატესობაა: მაგალითად, API-ის request ID, session token ან ანონიმური მომხმარებლის იდენტიფიკატორი. იმ სისტემებში, სადაც UUID v4 ინახება მხოლოდ იმიტირებისთვის, ინდექსის ფრაგმენტაცია არ წარმოადგენს პრობლემას.

UUID v4-ის გამოყენების სცენარები

აპლიკაციის დეველოპერები იყენებენ UUID v4-ს ობიექტების, სესიების ან მოვლენების უნიკალური იდენტიფიკატორებისთვის. იმიტირებული მონაცემთა ბაზის შევსებისას, 100 UUID v4-ის გენერირება 100 უნიკალურ გასაღებს ქმნის, რაც რეალურ მონაცემთა ბაზას ასახავს.

მონაცემთა ბაზის დიზაინერები იყენებენ UUID v4-ს იმ სისტემებში, სადაც ცენტრალური კოორდინაცია შეუძლებელია. მაგალითად, დისტრიბუციულ სისტემაში, რამდენიმე სერვერი ერთდროულად ქმნის ID-ებს, მაგრამ იცის, რომ ისინი უნიკალური იქნება. ეს შეუძლებელია auto-increment-ით: თუ ორი სერვერი ქმნის ID-ს, ისინი ერთმანეთს გადააბიჯებენ.

უსაფრთხოების ინჟინრები იყენებენ UUID v4-ს იმ ID-ებისთვის, რომლებიც გამოცნობადი არ უნდა იყოს. მაგალითად, API-ის access token-ისთვის, UUID v4-ის 122 ბიტიანი შემთხვევითობა იძლევა 2^122 ≈ 5.3 × 10^36 შესაძლო მნიშვნელობას. ამდენი მნიშვნელობიდან ერთის გამოცნობა პრაქტიკაში შეუძლებელია. UUID v7, რომელიც 48-ბიტიან timestamp-ს იყენებს, აადვილებს იდენტიფიკატორის შექმნის დროის განსაზღვრას.

ტესტერები იყენებენ UUID v4-ს მონაცემთა ბაზის იმიტირებისთვის. 100 UUID v4-ის გენერირება 100 უნიკალური key-ის შექმნას ნიშნავს, რომ თითოეულს 122-ბიტიანი მნიშვნელობა აქვს.

FAQ

რა განსხვავებაა UUID v4-სა და UUID v7-ს შორის?
UUID v4 იყენებს 122 ბიტ შემთხვევითობას, UUID v7 — 48-ბიტიან timestamp-ს + 74-ბიტიან random-ს. v7-ის იდენტიფიკატორები იზრდება დროთა განმავლობაში, რაც B-tree ინდექსს ნაკლებად ფრაგმენტირებს. v4-ის იდენტიფიკატორები სრულიად შემთხვევითია.

რამდენად ხშირად ხდება UUID v4-ის კოლიზია?
122-ბიტიანი შემთხვევითობის გამო, 1 მილიარდი UUID v4-ის გენერირების შემდეგაც, კოლიზიის ალბათობა 10^-18-ზე ნაკლებია. პრაქტიკაში, ეს ნიშნავს, რომ კოლიზია არასდროს მოხდება.

შეიძლება თუ არა UUID v4-ის 122-ბიტიანი მნიშვნელობის ჩანაცვლება 122-ბიტიანი random integer-ით?
დიახ, მაგრამ UUID v4-ის ფორმატი (8-4-4-4-12) იძლევა სტანდარტიზებულ, 36-სიმბოლოიან წარმოდგენას, რომელიც ფართოდ არის გავრცელებული. 122-ბიტიანი random integer 36-სიმბოლოიან ჰექსში იწერება 30.5 ჰექს ციფრის სახით (122/4 = 30.5), რაც 36-სიმბოლოიანი UUID v4-ის 32 ჰექს ციფრს + 4 დეფისს უდრის.

რატომ უნდა გამოვიყენო uppercase-ი?
Uppercase-ის გამოყენება ზრდის იდენტიფიკატორის ვიზუალურ განსხვავებას, მაგრამ RFC 4122 გვირჩევს lowercase-ს. თუ თქვენი API-ის endpoint-ები იყენებენ uppercase-ს, 120-100 ეს ინტერფეისის კონვენციაა.

რატომ არის 100-ზე მეტი count-ი აკრძალული?
100-ზე მეტი UUID v4-ის ერთდროულად გენერირებამ შეიძლება გამოიწვიოს ბრაუზერის მეხსიერების გადატვირთვა იმ მოწყობილობებზე, რომლებსაც ბევრი UUID-ს ერთდროულად შენახვა უჭირთ. 100-ზე მეტი count-ის მისაღებად, მომხმარებელმა უნდა გაიმეოროს გენერაცია.

როგორ იქმნება UUID v4 ბრაუზერში?
crypto.getRandomValues() API იღებს 16 ბაიტს (128 ბიტი) კრიპტოგრაფიულად ძლიერი შემთხვევითობით. 4 ბიტი (version) ფიქსირდება 4-ზე, 2 ბიტი (variant) ფიქსირდება RFC 4122-ის მიხედვით, ხოლო 122 ბიტი რჩება შემთხვევითი. 128-ბიტიანი მნიშვნელობა იწერება 36-სიმბოლოიანი ფორმატის 32 ჰექს ციფრში + 4 დეფისში.

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