UUID बनाम ULID: अपने एप्लिकेशन के लिए आइडेंटिफ़ायर चुनना

जनरेट किए आइडेंटिफ़ायर का एक काम है — अनोखा होना — साथ ही कुछ ऐसे जो रास्ते में जुड़ जाते हैं: बिना समन्वय के कहीं भी जनरेट होना, संक्षिप्त स्टोर होना, अनुमानित क्रम में सॉर्ट होना, और शर्मनाक कुछ भी न छोड़ना। UUID और ULID दोनों अनोखेपन की सीमा पार करते हैं; उसके बाद की हर चीज़ में अलग हैं।

• कोई समन्वय नहींविकेंद्रित जनरेशन: कोई भी सेवा, वर्कर या ब्राउज़र टैब केंद्रीय काउंटर से पूछे बिना आइडेंटिफ़ायर बना सकता है — यही दोनों फ़ॉर्मैट को वितरित सिस्टम में ढालता है।
• वही 128 बिटदोनों तरफ़ 128 बिट: UUID 128-बिट वैल्यू है जो हाइफ़न सहित 36 हेक्साडेसिमल कैरेक्टर में लिखी जाती है; ULID वही 128 बिट 26 base32 कैरेक्टर में रखता है।
• लेआउट ही फ़र्क हैअसली सवाल लेआउट है: कौन सी बिट रैंडम हैं और कौन सी समय एन्कोड करती हैं — यही तय करता है कि आइडेंटिफ़ायर इंडेक्स में कैसा व्यवहार करता है और क्या उजागर करता है।

RFC 9562 कई UUID वर्शन परिभाषित करता है, पर दो एप्लिकेशन काम पर हावी हैं। वर्शन 4, 128 में से 122 बिट यादृच्छता से भरता है और कुछ और एम्बेड नहीं करता; वर्शन 7 की शुरुआत मिलीसेकंड में 48-बिट Unix टाइमस्टैम्प से होती है और बाकी 74 बिट यादृच्छता से भरती हैं।

• v4: शुद्ध रैंडमv4 निजता-अधिकतम चुनाव है: वैल्यू इस बारे में कुछ नहीं कहती कि कब या कहाँ बनी, और 122 रैंडम बिट किसी भी एप्लिकेशन के कभी खर्च कर पाने से ज़्यादा अनोखेपन हैं।
• v7: पहले समयv7 मुख्यतः मिलीसेकंड टाइमस्टैम्प के आधार पर क्रमबद्ध होता है। एक ही मिलीसेकंड के भीतर और अलग डिवाइसों पर क्रम जेनरेटर और घड़ियों पर निर्भर है।
• v1 छोड़ेंपुराने वर्शन लेगसी हैं: v1 MAC पता और घड़ी की वैल्यू एम्बेड करता था, दोनों लीक करता था; v3 और v5 स्थिर ID निकालने के लिए नाम-आधारित हैश हैं, ताज़ी यादृच्छता नहीं।

ULID Crockford base32 के 26 कैरेक्टर हैं: पहले 10 कैरेक्टर 48-बिट मिलीसेकंड टाइमस्टैम्प एन्कोड करते हैं, बाकी 16, 80 रैंडम बिट। अक्षरमाला जानबूझकर I, L, O और U को छोड़ती है, ताकि आइडेंटिफ़ायर ज़ोर से पढ़े जाने या स्क्रीनशॉट से टाइप किए जाने पर बचे रहें।

• स्ट्रिंग सॉर्ट = समय सॉर्टशब्दकोश क्रम ही समय क्रम है: ULID को सादी स्ट्रिंग के रूप में सॉर्ट करना उन्हें बिना पार्स किए निर्माण समय से सॉर्ट करता है — लॉग लाइनों, फ़ाइल नामों और key-value स्टोर में उपयोगी।
• 26 सुरक्षित कैरेक्टरसंक्षिप्त और URL-सेफ़: 26 केस-असंवेदनशील कैरेक्टर, बिना हाइफ़न या प्रतीक, UUID के 36 से छोटे और किसी भी पाथ सेगमेंट या क्वेरी पैरामीटर में सुरक्षित।
• प्रति मिलीसेकंड एकदिशएक ही मिलीसेकंड के भीतर क्रम रैंडम हिस्से से आता है; जिन जनरेटर इसे एकदिश रूप से बढ़ाते हैं — जैसे Toolars बैच जनरेटर — वे समान-मिलीसेकंड आइडेंटिफ़ायर भी जनरेशन क्रम में रखते हैं।

B-tree इंडेक्स क्रमबद्ध होता है, और रैंडम UUID v4 डालना हर बार किसी बेतरतीब पत्ते में लिखता है: पेज टूटते हैं, बफ़र कैश हिलता है, और इंडेक्स मृत जगह से फूलता है। समय-क्रमित आइडेंटिफ़ायर इंडेक्स के दाएँ किनारे के पास जुड़ते हैं, इन्सर्ट को B-tree के सर्वोत्तम केस में बदलते हुए।

यही वजह है कि चुनाव स्कीमा डिज़ाइन समय का है, पहले धीमे तिमाही के बाद का नहीं: प्राथमिक कुंजी का माइग्रेशन हर पंक्ति और उसे संदर्भित करने वाली हर फ़ॉरेन कुंजी को फिर लिखना है। अगर टेबल छोटी रहेगी, तो v4 की अव्यवस्था कभी दिखेगी नहीं; अगर वह लगातार राइट्स के नीचे करोड़ों पंक्तियों में बढ़ेगी, तो क्रमबद्ध फ़ॉर्मैट पहले दिन से किराया चुकाते हैं।

• रैंडम बिखराता हैv4 को प्राथमिक कुंजी बनाने पर इन्सर्ट-भारी टेबल ज़्यादा पेज स्प्लिट, कम फ़िल फ़ैक्टर और मापने योग्य खराब राइट थ्रूपुट दिखाती हैं — समान आकार की क्रमबद्ध कुंजी की तुलना में।
• क्रमबद्ध जोड़ता हैv7 और ULID बिना केंद्रीय तालमेल के इंडेक्स स्थानीयता सुधारते हैं। एक ही बढ़ते बैच के पास-पास ID अनुमान योग्य हो सकते हैं; अनुमति जाँच ID से अलग लागू करें।
• सौदा मापेंसौदा असली है पर मामूली: 128 बिट bigint के स्टोरेज से दोगुनी है, और समय-क्रमित कुंजियाँ आज की राइट्स को इंडेक्स के दाएँ किनारे पर केंद्रित करती हैं, जो सिर्फ़ बहुत तेज़ इन्सर्ट दरों पर मायने रखता है।

v4 के 122 स्वतंत्र रैंडम बिट के साथ एक अरब ID की टक्कर की संभावना लगभग 10^19 में एक है। ULID के 80 रैंडम बिट अलग संदर्भ में काम आते हैं: एक ही मिलीसेकंड में बने ID।

कोई भी संदिग्ध वैल्यू वैलिडेटर में पेस्ट करें: वह अपने RFC 9562 वेरिएंट और वर्शन निबल के साथ कैननिकल 36-कैरेक्टर UUID आकार पहचानता है, अपने ओवरफ़्लो नियम के साथ 26-कैरेक्टर ULID अक्षरमाला, और समय-क्रमित फ़ॉर्मैट के लिए एम्बेड किया टाइमस्टैम्प बताता है — ताकि लॉग की वैल्यू आपको बता दे कि वह क्या है, इससे पहले कि आप उस पर कुछ बनाएँ।

• संभाव्यता नगण्यकोई भी फ़ॉर्मैट सुरक्षा सीमा नहीं है: URL में आइडेंटिफ़ायर पते के लिए ठीक है, पर जो उसे देखे वह उद्धृत कर सकता है — प्राधिकरण एक्सेस जाँच से आना चाहिए, ID के अपारदर्शिता से नहीं।
• ID सीक्रेट नहींv7 और ULID डिज़ाइन से निर्माण समय लीक करते हैं; वैलिडेटर उसे खुलेआम निकालता है। यह आमतौर पर हानिकारक मेटाडेटा नहीं है, पर सार्वजनिक ऑब्जेक्ट के लिए सोचकर तय करें।
• समय दिखता हैक्रमिक डेटाबेस ID आयतन और वृद्धि दर लीक करती हैं; रैंडम और समय-रैंडम आइडेंटिफ़ायर इस बारे में कुछ नहीं बताते कि कितने रिकॉर्ड मौजूद हैं।

आइडेंटिफ़ायर जनरेशन को ठीक एक दुर्लभ संसाधन चाहिए — अच्छी यादृच्छता — और ब्राउज़र के पास वह पहले से है। वर्कस्पेस crypto.getRandomValues से लेता है, बैच पूरी तरह टैब में जनरेट करता है, और कोई वैल्यू कभी ट्रांसमिट नहीं करता।

• प्रति बैच 1–100UUID v4, UUID v7 या ULID चुनें और प्रति बैच 1 से 100 जनरेट करें; v7 और ULID बैच रैंडम फ़ील्ड को एकदिश रूप से बढ़ाते हैं, ताकि पूरा बैच जनरेशन क्रम में रहे।
• केस और एक्सपोर्टआउटपुट केस डिस्प्ले की पसंद है: कैननिकल, बड़े अक्षर, या छोटे अक्षर — copy-all के साथ, और न्यूलाइन-अलग टेक्स्ट व CSV डाउनलोड जो हर आइडेंटिफ़ायर का एम्बेड किया समय दर्ज करते हैं।
• तुरंत वैलिडेशनवैलिडेशन संरचना के सवालों का तुरंत जवाब देता है: लंबाई, अक्षरमाला, UUID वर्शन और वेरिएंट, nil और max विशेष वैल्यू, ULID ओवरफ़्लो, और UTC में एम्बेड किया टाइमस्टैम्प।