UUID लगभग कभी क्यों नहीं टकराते (बिना जाँचे भी)

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

क्लासिकल बर्थडे पैराडॉक्स यह पूछता है कि किसी कमरे में इतने लोग जमा होने से पहले कि उनमें से दो के जन्मदिन एक जैसे होने की संभावना 50 प्रतिशत से ज़्यादा हो जाए, कितने लोग चाहिए — और जवाब — सिर्फ़ 23 लोग, जबकि 365 मुमकिन जन्मदिन हैं — ज़्यादातर लोगों को हैरान कर देता है, जो सहज रूप से उम्मीद करते हैं कि यह संख्या 365 के काफ़ी क़रीब होगी। असली जवाब इतना छोटा होने की वजह यह है कि असल तुलना "क्या कोई ख़ास शख़्स मेरे जन्मदिन जैसा जन्मदिन रखता है" नहीं है, बल्कि "क्या कमरे में मौजूद सभी मुमकिन जोड़ों में से कोई भी जोड़ा एक जैसा जन्मदिन रखता है" है — और मुमकिन जोड़ों की संख्या लोगों की संख्या से कहीं तेज़ी से बढ़ती है, क्योंकि 23 लोगों के साथ पहले से ही 253 अलग-अलग जोड़े मौजूद हैं, हर एक मेल खाने का एक स्वतंत्र मौक़ा। यही ठीक गणितीय पैटर्न — तुलना के मौक़ों की संख्या का वर्गानुपाती रूप से बढ़ना जबकि आइटम की संख्या सिर्फ़ रैखिक रूप से बढ़े — बर्थडे प्रॉब्लम कहलाता है, और यह उस हर स्थिति पर सीधे लागू होता है जिसमें किसी तय जगह से रैंडम वैल्यू चुनी जाती हैं और डुप्लिकेट के लिए जाँची जाती हैं — UUID बिल्कुल इसी में फ़िट बैठते हैं।

कोई स्टैंडर्ड रैंडम UUID (वर्ज़न 4) 122 वाक़ई रैंडम बिट्स की जगह से चुना जाता है — कुल 128 बिट्स में से मुट्ठी भर बिट्स वर्ज़न पहचानने के लिए फ़ॉर्मेट की स्पेसिफ़िकेशन द्वारा ही तय कर दिए जाते हैं — जिसका मतलब है कि मुमकिन वैल्यू की कुल संख्या 2 की घात 122 है, यानी एक ऐसी संख्या जो लगभग समझ से परे बड़ी है। 365-दिन वाले उदाहरण के लिए इस्तेमाल हुए बर्थडे-पैराडॉक्स तर्क को उसी तरह लगाना, लेकिन उस कहीं ज़्यादा बड़ी जगह पर बड़े पैमाने पर, वह बिंदु देता है जहाँ कोई टकराव होने की संभावना बनती है: किसी टकराव की संभावना के लगभग 50 प्रतिशत तक पहुँचने से पहले लगभग 2.7 क्विंटिलियन UUID जनरेट करने पड़ेंगे — पैमाना समझने के लिए, यह पृथ्वी के हर समुद्र-तट पर अनुमानित रेत के कणों से भी ज़्यादा UUID है। कोई अकेला सिस्टम, या यहाँ तक कि कई सिस्टम मिलकर, किसी भी असली दुनिया की व्यावहारिक दर पर UUID जनरेट करते हुए, उस सीमा के क़रीब पहुँचने में ब्रह्मांड की उम्र से कहीं ज़्यादा समय लगा देंगे — यही वह असली गणितीय आधार है जिसकी वजह से UUID टकराव को व्यवहार में जाँचने की ज़रूरत ही नहीं मानी जाती।

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

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