UUID क्या है? v4 बनाम v7, UUID बनाम GUID और ULID

UUID फ़ॉर्मेट

सभी UUID का लेआउट एक जैसा है, जिसे RFC 9562 (जिसने 2024 में RFC 4122 की जगह ली) परिभाषित करता है। तीसरा ग्रुप वर्ज़न अंक से शुरू होता है और चौथा ग्रुप वेरिएंट एन्कोड करता है; बाकी वर्ज़न-विशेष डेटा है।

xxxxxxxx-xxxx-Vxxx-Nxxx-xxxxxxxxxxxx
                 ^    ^
         version ─┘    └─ variant (8, 9, a or b for RFC UUIDs)

3f2504e0-4f89-41d3-9a0c-0305e82c3301   ← version 4 (random)
018f4a2c-9b3e-7d21-8c4f-1e2d3a4b5c6d   ← version 7 (time-ordered)

आज़माएँ: UUID जनरेटर

UUID वर्ज़न: v1, v4, v5 और v7

• v1 — टाइमस्टैम्प और मशीन का MAC एड्रेस। यूनिक और सॉर्टेबल, लेकिन हार्डवेयर एड्रेस और बनने का समय लीक करता है; नए सिस्टम में शायद ही इस्तेमाल होता है।
• v4 — 122 रैंडम बिट। सबसे आम वर्ज़न: कोई तालमेल नहीं, कुछ लीक नहीं, बेहद सरल। इसकी एकमात्र कमज़ोरी यह है कि रैंडम key डेटाबेस इंडेक्स में इंसर्ट को बिखेर देती हैं।
• v3 और v5 — नेमस्पेस और नाम को हैश करके बनते हैं (v3 के लिए MD5, v5 के लिए SHA-1)। एक ही इनपुट हमेशा एक ही UUID देता है, जो डिटरमिनिस्टिक id के लिए उपयोगी है।
• v7 — 48-बिट Unix मिलीसेकंड टाइमस्टैम्प और उसके बाद रैंडम बिट। बनने के समय से सॉर्टेबल, इंडेक्स-फ़्रेंडली और फिर भी अप्रत्याशित। RFC 9562 नई डेटाबेस key के लिए इसकी सिफ़ारिश करता है।

आज़माएँ: UUID जनरेटर

UUID v4 बनाम v7: कौन-सा इस्तेमाल करें?

v7 तब इस्तेमाल करें जब UUID डेटाबेस प्राइमरी key हो या कुछ भी ऐसा जो इंडेक्स होकर हाल के हिसाब से क्वेरी होता है। क्योंकि v7 वैल्यू समय के साथ बढ़ती हैं, नई रो B-tree इंडेक्स के अंत में आती हैं, रैंडम जगहों पर नहीं, जिससे PostgreSQL, MySQL और SQL Server पर इंसर्ट तेज़ और पेज कैश-फ़्रेंडली रहते हैं। id से सॉर्ट करना बनने के समय से सॉर्ट करना भी बन जाता है।

v4 तब इस्तेमाल करें जब आइडेंटिफ़ायर को कुछ भी नहीं बताना चाहिए — यह भी नहीं कि वह लगभग कब बना — जैसे पब्लिक टोकन, अनसब्सक्राइब लिंक या कुछ भी जिसे हमलावर enumerate कर सकता है। बाकी सब के लिए 2026 में v7 सुरक्षित डिफ़ॉल्ट है।

आज़माएँ: UUID जनरेटर आज़माएँ: ULID जनरेटर

UUID बनाम GUID बनाम ULID

• GUID उसी 128-बिट आइडेंटिफ़ायर का Microsoft वाला नाम है। .NET या SQL Server का GUID एक UUID ही है; फ़र्क़ सिर्फ़ दिखावटी हैं (ब्रेसेस, अपर केस) और कुछ Windows API में बाइट-ऑर्डर की एक ऐतिहासिक विचित्रता।
• ULID एक वैकल्पिक 128-बिट id है जो 48-बिट टाइमस्टैम्प और 80 रैंडम बिट को Crockford Base32 में 26 कैरेक्टर के रूप में एन्कोड करता है (01ARZ3NDEKTSV4RRFFQ69G5FAV)। यह v7 की तरह सॉर्टेबल है और पढ़ने-टाइप करने में छोटा, लेकिन RFC स्टैंडर्ड नहीं है और जहाँ भी इस्तेमाल हो वहाँ लाइब्रेरी चाहिए।
• ऑटो-इंक्रीमेंट इंटीजर छोटे और तेज़ हैं, लेकिन सेंट्रल सीक्वेंस माँगते हैं और बताते हैं कि कितने रिकॉर्ड मौजूद हैं। कई सिस्टम अंदर इंटीजर और बाहर UUID इस्तेमाल करते हैं।

आज़माएँ: ULID जनरेटर

क्या दो UUID टकरा सकते हैं?

v4 UUID में 122 रैंडम बिट होते हैं, यानी लगभग 5.3 × 10³⁶ संभावित वैल्यू। एक डुप्लिकेट की 50% संभावना तक पहुँचने के लिए आपको लगभग 2.7 × 10¹⁸ UUID बनाने होंगे — एक सदी तक हर सेकंड अरबों। व्यवहार में कॉलिज़न बग से आते हैं (सीडेड या ख़राब इम्प्लीमेंट किया रैंडम जनरेटर, कॉपी-पेस्ट की गई id), संयोग से कभी नहीं।

UUID जनरेट, वैलिडेट और स्टोर करना

• प्लेटफ़ॉर्म से जनरेट करें: JavaScript में crypto.randomUUID(), Python में uuid.uuid4(), Java में java.util.UUID, PostgreSQL में gen_random_uuid()। सभी क्रिप्टोग्राफ़िक रूप से सुरक्षित सोर्स इस्तेमाल करते हैं।
• शेप से वैलिडेट करें: 36 कैरेक्टर, hex अंक, 8, 13, 18 और 23 पोज़िशन पर हाइफ़न, 1–8 का वर्ज़न अंक और 8, 9, a या b का वेरिएंट अंक। लोअर केस कैनोनिकल रूप है।
• नेटिव 16-बाइट टाइप में स्टोर करें (PostgreSQL में uuid, MySQL में BINARY(16), SQL Server में UNIQUEIDENTIFIER), 36-कैरेक्टर स्ट्रिंग में नहीं — इससे इंडेक्स साइज़ आधा हो जाता है।
• यूज़र डेटा से UUID तब तक न निकालें जब तक v5 की डिटरमिनिज़्म न चाहिए, और v4 UUID को पासवर्ड जैसी सावधानी वाला सीक्रेट न मानें: यह अनुमान से परे है, लेकिन लॉग और URL में भी छपता है।

आज़माएँ: UUID जनरेटर आज़माएँ: रैंडम सीक्रेट जनरेटर आज़माएँ: SQL INSERT जनरेटर

अक्सर पूछे जाने वाले सवाल