UUID जेनरेटर

कोई UUID एक 128-बिट आइडेंटिफ़ायर है जिसे किसी भी संख्या के अलग सिस्टम द्वारा, किसी भी पल, बिना अगला उपलब्ध नंबर देने वाले किसी केंद्रीय समन्वयक अधिकारी के, स्वतंत्र रूप से जेनरेट करने के लिए डिज़ाइन किया गया है, जबकि फिर भी इस बात की भारी सांख्यिकीय गारंटी बनाए रखता है कि जेनरेट किए दो वैल्यू कभी नहीं टकराएँगे। यह किसी ऑटो-इंक्रीमेंट इंटीजर ID से बुनियादी तौर पर अलग है, जिसे अगला नंबर क्रम में ट्रैक और देने के लिए एक ही डेटाबेस चाहिए — कोई UUID बिना नेटवर्क कनेक्शन वाले मोबाइल पर, किसी सर्वरलेस फ़ंक्शन में, या एक साथ हज़ार समानांतर माइक्रोसर्विस इंस्टेंस में जेनरेट हो सकता है, उनके बीच बिल्कुल भी किसी समन्वय की ज़रूरत के बिना, क्योंकि नंबर की जगह का साइज़ ही किसी इत्तेफ़ाक़न टकराव को खगोलीय रूप से असंभावित बना देता है चाहे कितने भी स्वतंत्र रूप से जेनरेट किए जाएँ।

UUID वर्ज़न 4 बुनियादी तौर पर पूरे 128 बिट को क्रिप्टोग्राफ़िक रूप से रैंडम डेटा से भर देता है, जिससे हर जेनरेट की वैल्यू पूरी तरह अप्रत्याशित बन जाती है और यह कोई संकेत नहीं देती कि यह कब बनाई गई या किसी दूसरे UUID v4 के मुक़ाबले किस सापेक्ष क्रम में — किसी सिक्योरिटी टोकन जैसी चीज़ के लिए बिल्कुल वही चाहा गया गुण, जहाँ अनुमान लगाने लायक़पन ख़ुद एक कमज़ोरी होगी। UUID वर्ज़न 7, जो RFC 9562 (2024) में कहीं ज़्यादा हाल में मानकीकृत हुआ, जान-बूझकर उस अस्पष्टता का कुछ हिस्सा त्याग देता है: यह शुरुआती बिट में मिलीसेकंड-सटीकता वाला टाइमस्टैंप रखता है, तो बाद में जेनरेट किया कोई UUID v7 हमेशा पहले जेनरेट किए किसी के बाद क्रमबद्ध होता है, जबकि बाक़ी बिट रैंडम रहते हैं और v4 जितने ही अनुमान लगाने में नामुमकिन रहते हैं। दोनों प्रतिस्पर्धी डिज़ाइन नहीं हैं जहाँ एक बस "बेहतर" हो — ये एक जैसी अंतर्निहित रैंडमनेस को एक अलग गुण के बदले व्यापार करते हैं, इस पर निर्भर करते हुए कि किसी दिए इस्तेमाल के मामले के लिए असल में क्या मायने रखता है — क्रमबद्धता या एक जैसी अप्रत्याशितता।

किसी प्राइमरी की को सपोर्ट करने वाला डेटाबेस इंडेक्स आमतौर पर B-tree के रूप में स्टोर होता है, एक ऐसी संरचना जो सबसे बेहतर तब काम करती है जब नई वैल्यू मौजूदा क्रमबद्ध ऑर्डर के अंत में या उसके क़रीब डाली जाएँ — जो ठीक वैसा है जैसा कोई पारंपरिक ऑटो-इंक्रीमेंट इंटीजर की व्यवहार करती है। कोई UUID v4 प्राइमरी की, एक जैसी रैंडम होने की वजह से, हर बार उस क्रमबद्ध संरचना के अंदर एक असल में रैंडम स्थिति पर डाली जाती है, जो डेटाबेस को अंत में बस जोड़ने की बजाय पूरे ट्री में बिखरे इंडेक्स पेज को बार-बार बाँटने और दोबारा संतुलित करने पर मजबूर करता है। छोटे स्केल पर यह अतिरिक्त बोझ अदृश्य है; बड़े स्केल पर, लाखों पंक्तियों के साथ, यह इंडेक्स फ़्रैगमेंटेशन और धीमी लिखाई का एक असली और मापने लायक़ स्रोत बन जाता है — ठीक वह समस्या जिसे हल करने के लिए UUID v7 का शुरुआती टाइमस्टैंप ख़ास तौर पर मानकीकृत किया गया, क्योंकि यह किसी UUID को यूनीक और अनुमान लगाने में नामुमकिन ID बनाए रखने देता है जबकि फिर भी लगभग क्रमबद्ध क्रम में डाला जाता है।