संक्षेप में: UUID v4 यादृच्छिक यूनिक ID के लिए सुरक्षित डिफ़ॉल्ट है, ULID तब बेहतर है जब आपको निर्माण-समय से क्रमबद्ध होने वाली ID भी चाहिए, और NanoID तब आदर्श है जब छोटी, URL-अनुकूल ID चाहिए। तीनों सिस्टमों के बीच समन्वय टालते हैं, पर लंबाई, क्रमबद्धता और इंडेक्स-व्यवहार में अलग-अलग संतुलन रखते हैं। यह गाइड बताती है हर एक क्या है और कब उपयोग करें।
एक यूनिक पहचानकर्ता स्वतंत्र सिस्टमों को किसी केंद्रीय सर्वर से «अगला नंबर क्या है?» पूछे बिना रिकॉर्ड बनाने देता है। यही स्वतंत्रता मूल बात है: दो सेवाएँ, या दो ऑफ़लाइन डिवाइस, हर एक अपनी ID बना सकते हैं और भरोसा रख सकते हैं कि मान टकराएँगे नहीं।
UUID वास्तव में है क्या
UUID 128-बिट मान है, सामान्यतः 36 अक्षरों में लिखा जाता है — 32 हेक्साडेसिमल अंक और चार हाइफ़न, जैसे 550e8400-e29b-41d4-a716-446655440000। जो संस्करण आप लगभग हमेशा चाहेंगे वह है UUID v4, जो उन बिट्स में से 122 को यादृच्छिकता से भरता है। इससे लगभग 5.3 × 10³⁶ संभावित मान बनते हैं, इसलिए टकराव की चिंता जरूरी नहीं: किसी टकराव की 50% संभावना तक पहुँचने से पहले आपको लगभग सौ करोड़ अरब UUID बनाने पड़ेंगे।
«नगण्य» का अर्थ «असंभव» नहीं, पर व्यवहार में v4 बिना किसी केंद्रीय समन्वय के विशिष्टता देता है।
UUID v4 बनाम v1
UUID v1 एक टाइमस्टैम्प और जनरेट करने वाली मशीन के नेटवर्क (MAC) पते से बनता है। इससे v1 मोटे तौर पर समय-क्रम में रहता है, पर यह उजागर कर सकता है कि ID कहाँ और कब बनी — कभी-कभी गोपनीयता की चिंता। UUID v4 यह सब छोड़ शुद्ध यादृच्छिकता अपनाता है: कोई क्रम नहीं, कोई अंतर्निहित मेटाडेटा नहीं, उजागर करने को कुछ नहीं। अधिकांश अनुप्रयोगों के लिए v4 सही डिफ़ॉल्ट है, और v1 तभी सार्थक है जब आपको खासकर उसका समय-घटक चाहिए।
ULID: डिज़ाइन से क्रमबद्ध
ULID भी 128 बिट का है, पर हाइफ़न वाले हेक्स के बजाय 26 Crockford base32 अक्षरों में एन्कोडेड। इसके पहले 48 बिट मिलीसेकंड टाइमस्टैम्प हैं और शेष 80 यादृच्छिक। चूँकि टाइमस्टैम्प आगे है, ULID निर्माण-क्रम में शब्दकोशीय रूप से क्रमबद्ध होते हैं: स्ट्रिंग्स को क्रमित करें और कालानुक्रमिक क्रम मुफ़्त मिल जाता है। यह वाकई उपयोगी गुण है: «सबसे नए पहले» प्रश्नों को सस्ता बनाता है और डेटाबेस इंसर्ट को बिखरे नहीं बल्कि क्रमबद्ध रखता है।
NanoID: छोटा और URL-अनुकूल
NanoID डिफ़ॉल्ट रूप से URL-सुरक्षित वर्णमाला के 21 अक्षर उपयोग करता है, इसलिए बिना percent-encoding लिंक में समा जाता है। लंबाई विन्यास-योग्य है, जिससे आप आकार और टकराव-प्रतिरोध में संतुलन बना सकते हैं: छोटी ID साफ-सुथरी होती हैं पर कम यादृच्छिकता छोड़ती हैं, इसलिए सार्वजनिक या उच्च-मात्रा पहचानकर्ताओं के लिए इन्हें लंबा रखें। NanoID शेयर लिंक, छोटे सार्वजनिक ID, और जहाँ 36-अक्षर UUID URL में भारी लगे, वहाँ चमकता है।
डेटाबेस कुंजी के लिए कौन सा?
यहाँ चुनाव के वास्तविक प्रदर्शन-परिणाम हैं। UUID v4 प्राइमरी कुंजी के रूप में पूरी तरह मान्य है, पर इसकी यादृच्छिकता नई पंक्तियों को B-tree इंडेक्स में यादृच्छिक स्थानों पर डालती है, जिससे तालिका बढ़ने पर विखंडन और अधिक पेज-स्प्लिट होते हैं। समय-क्रमित पहचानकर्ता — ULID, या नया UUID v7 — मोटे तौर पर बढ़ते क्रम में इन्सर्ट होते हैं, जिससे इंडेक्स सघन और लेखन स्थानीय रहते हैं। बड़ी, लेखन-भारी तालिका की कुंजी चुनते समय समय-क्रमित ID को प्राथमिकता दें; छोटी तालिकाओं में अंतर विरले ही मायने रखता है।
बचने योग्य आम ग़लतियाँ
- जब आप अनुमान-रहित ID चाहते थे तब क्रमिक पूर्णांक ID सार्वजनिक करना — यह यादृच्छिक ID का काम है, ऑटो-इंक्रीमेंट का नहीं।
- यादृच्छिक UUID v4 को विशाल तालिका की क्लस्टर्ड की बनाना, फिर हैरान होना कि इन्सर्ट धीमे क्यों हैं।
- «जगह बचाने» के लिए UUID काटना — आप वह यादृच्छिकता फेंक देते हैं जो विशिष्टता की गारंटी देती है।
- उच्च-मात्रा पहचानकर्ता के लिए NanoID को बहुत छोटा करना और टकराव का जोखिम बढ़ाना।
ID को काम से मिलाएँ: UUID जेनरेटर से v4, v1, ULID या NanoID मान बनाएँ, सामान्य विशिष्टता के लिए v4 चुनें, क्रम मायने रखे तो ULID, और ID को URL में रहना हो तो NanoID।