UUID के वर्ज़न और उन्हें कब इस्तेमाल करें

 (ntietz.com)
3 पॉइंट द्वारा GN⁺ 2024-08-27 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • UUID के v1 से v8 तक 8 वर्ज़न हैं, और बड़ा नंबर होने का मतलब यह नहीं कि वह ज़्यादा नया या बेहतर है; RFC 9562 में बस अलग-अलग generation methods परिभाषित हैं
  • आम तौर पर विकल्प v4 और v7 तक सिमट जाते हैं; v4 random ID के लिए default है और v7 तब उपयुक्त है जब generation time के क्रम में sorting चाहिए
  • v1 और v6 एक ही तरह की सामग्री का उपयोग करते हैं, लेकिन v6 में field order इस तरह बदला गया है कि sort करने पर वह generation time के क्रम में आए
  • v3 और v5 input data को hash करके UUID बनाते हैं; v3 MD5 और v5 SHA-1 का उपयोग करता है, और candidate input values के रूप में DNS और URL हो सकते हैं
  • जहाँ संभव हो v1·v6 की जगह v7 का उपयोग करना, input data-आधारित UUID चाहिए तो v5 देखना, और पूरी तरह custom UUID चाहिए तो v8 पर विचार करना एक व्यावहारिक तरीका है

UUID वर्ज़न के अनुसार generation method

  • UUID वर्ज़न v1 से v8 तक हैं और सभी RFC 9562 में परिभाषित हैं

  • समय-आधारित UUID

    • UUID Version 1 timestamp, monotonic counter, और MAC address से बनता है
    • UUID Version 6 v1 जैसा ही data इस्तेमाल करता है, लेकिन order इस तरह बदलता है कि sort करने पर generation time के क्रम में आए
    • UUID Version 7 timestamp और random data से बनता है

  • random·custom UUID

    • UUID Version 4 पूरी तरह random data से बनता है, और यह उस रूप के सबसे करीब है जिसे ज़्यादातर लोग UUID कहकर सोचते हैं
    • UUID Version 8 सभी वर्ज़न में ज़रूरी version/variant fields को छोड़कर पूरी तरह user-defined format है

  • input data hash-आधारित UUID

    • UUID Version 3 user द्वारा दिए गए data के MD5 hash से बनता है
      • RFC में candidate input values के रूप में DNS और URL शामिल हैं
    • UUID Version 5 user द्वारा दिए गए data के SHA-1 hash से बनता है
      • v3 की तरह इसमें भी DNS और URL input candidates हो सकते हैं

  • आरक्षित UUID

    • UUID Version 2 security ID के लिए reserved है और इसके ज्ञात विवरण उपलब्ध नहीं हैं

व्यवहारिक चयन मानदंड

  • अधिकांश मामलों में विकल्प v4 या v7 होते हैं
  • अगर बस एक random ID चाहिए, तो v4 default choice के रूप में उपयुक्त है
  • अगर ID को sort किया जा सकना चाहिए, तो v7 पर विचार किया जा सकता है
    • उदाहरण के लिए, UUID को database key के रूप में इस्तेमाल करते समय v7 एक उम्मीदवार हो सकता है
  • v5 या v8 उन मामलों के अधिक करीब हैं जहाँ आप UUID के अंदर अपना data डालना चाहते हैं
    • ऐसे मामलों में आम तौर पर user को पहले से पता होता है कि उसे यही चाहिए
  • RFC के अनुसार v7, v1 और v6 में सुधार करता है, इसलिए जहाँ संभव हो v1·v6 की जगह v7 इस्तेमाल करना चाहिए
    • अगर v1 या v6 सचमुच ज़रूरी हों, तो v6 का उपयोग किया जा सकता है
  • v2 किसी अनिर्दिष्ट security use के लिए reserved है
  • v3 को अधिक मजबूत hash इस्तेमाल करने वाले v5 ने replace कर दिया है, और जिन मामलों में v3 चाहिए, वहाँ भी अक्सर user को पहले से इसका कारण पता होता है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-08-27
Hacker News की रायें

  • UUID v2 की जानकारी नहीं है, यह बात सिर्फ़ कुख्यात रूप से अस्पष्ट RFC पढ़ने पर लागू होती है: https://pubs.opengroup.org/onlinepubs/9696989899/chap5.htm#t...
    इसका सामना लगभग कभी नहीं होगा, लेकिन version 0 UUID भी मौजूद है। यह उन reserved bits का स्रोत है जिनसे बाद में दूसरे “version” compatible तरीके से परिभाषित हो सके, इसलिए इसका ज़िक्र करना ठीक है। संबंधित पड़ताल मैंने अपनी UUID लाइब्रेरी में整理 कर रखी है: https://github.com/okeeblow/DistorteD/blob/NEW%E2%80%85SENSA...
    अच्छा लगा इसलिए support करने का फैसला किया, लेकिन date rollover और उससे भी पुराने Apollo UID को कैसे handle करना है, यह अभी तय करना बाकी है

    • RFC9562 ने निष्पक्ष रूप से कहें तो UUID Version 2 specification वाले दो documents cite किए हैं। हालांकि RFC4122 मेरे taste के हिसाब से बहुत ज़्यादा cipher text जैसा था
      0-7 Variant space में परिभाषित historical UUID types के लिए मैं एक informational RFC पर काम शुरू कर रहा/रही हूँ, जिससे लोगों को समझने में मदद मिलेगी। अगर चर्चा करनी हो या wording review करना हो, तो https://github.com/yocto/draft-yocto-uuid देख सकते हैं

  • जानकारी 2 मिनट में मिल गई। लेख में दिए link पर क्लिक करके RFC 9562 के DCE definition section में जाएँ, उस paragraph के पहले link से specification में जाएँ, फिर “UUID” search करके Appendix A पर जाएँ—सब कुछ वहीं है
    नाम थोड़ा भ्रमित करने वाला “Universal Unique Identifier” है, लेकिन ज़रूरी सारी जानकारी मौजूद है। अपने ही लेख में लगाए link पर कम से कम खुद क्लिक कर लेना चाहिए

    • यहाँ सीखने वाली दो बातें हैं। एक है v2 UUID specification पढ़ना, और दूसरी है UUID से generation के समय की situation information निकालना
      context में बाकी versions को specific elements से generated बताया गया है, इसलिए वह sentence स्पष्ट रूप से दूसरी चीज़ के बारे में है। sentence थोड़ा अस्पष्ट है, लेकिन इसे misleading कहना मुश्किल है
    • मैंने भी बिल्कुल वही process follow किया, और लगा कि details पर ज़्यादा ध्यान नहीं दिया गया है, इसलिए मैंने लेख को अंत तक नहीं पढ़ा
      फिर भी appendix उस समय के snapshot की तरह पढ़ने में मज़ेदार था
    • शायद यह language model द्वारा लिखा गया लेख भी हो सकता है

  • 73WakrfVbNJBaAmhQtEeDv या bK7nP9xM जैसा कोई short UUID standard हो तो अच्छा होगा
    सख्ती से देखें तो कहीं न कहीं duplicate हो सकता है, इसलिए UUID नहीं होगा, लेकिन मैं random होने के साथ याद रखने लायक छोटा ID standard combination चाहता/चाहती हूँ

    • सबसे नज़दीक ULID लगता है। 26-character base32 है, इसलिए छोटा है, 128-bit है, और lexicographic sorting भी संभव है
      मेरे हिसाब से कोई और ज़्यादा popular standard न होने की वजह यह है कि कुछ न कुछ छोड़ना पड़ता है। 128-bit लगभग हर use case में collision risk कम रखता है, लेकिन जितना छोटा करेंगे, उतना ही specific situation और collision के impact को देखना पड़ेगा, इसलिए standard बनाना मुश्किल हो जाता है। base64 या base85 जैसी दूसरी encodings इस्तेमाल करने पर यह और छोटा हो सकता है, लेकिन case sensitivity, URL safety जैसी चीज़ों की कुर्बानी देनी पड़ती है: https://github.com/ulid/spec
    • अगर ज़्यादा compact UUID चाहिए, तो मौजूदा UUID को URL-safe base64 में बदलकर 22-character form में दिखाया जा सकता है
      यह उसी UUID का सिर्फ़ दूसरा representation है और वापस बदला जा सकता है। UUID आखिरकार 128-bit value है, इसलिए यह असल conversion से ज़्यादा alternative notation है
    • Sqids शायद सही हो सकता है। यह UUID से काफी छोटे ID बनाता है, लेकिन universally unique नहीं होते और integer sequence से generate होते हैं: https://sqids.org/
    • आम तौर पर N-bit random number बनाकर उसे base58 में encode करते हैं। N जितना चाहें चुन सकते हैं
      कुछ UUID versions में मिलने वाला monotonic sorting advantage खो जाता है, लेकिन base58 URL-safe है और special characters शामिल नहीं करता। value फिर भी binary में store की जा सकती है। उदाहरण के लिए Postgres में text column की जगह bytea इस्तेमाल कर सकते हैं
    • 128-bit UUID को छोटे text form में दिखाने के लिए alternative encoding techniques standardize करने पर काम चल रहा है
      चर्चा यहाँ देखी जा सकती है: https://github.com/uuid6/new-uuid-encoding-techniques-ietf-d...

  • UUID v7 का timestamp Databend के लिए बड़ा बदलाव था। AWS S3 में metadata files को timestamp से जल्दी खोजने में इसका इस्तेमाल कर रहे हैं, इसलिए vacuum जैसी operations काफी तेज़ हो गईं
    PR: https://github.com/datafuselabs/databend/pull/16049

    • दिलचस्प तो है, लेकिन time के आधार पर खोजने के लिए UUID इस्तेमाल करना मुझे आसानी से सूझता नहीं। मैं होता/होती तो अलग timestamp field रखता/रखती
      time-ordered UUID का बड़ा फायदा locality बेहतर होना है। index में नया item डालते समय आम तौर पर वह पीछे append करने जैसा काम बनता है, जो random insert से सस्ता हो सकता है। हालांकि contention बढ़ भी सकता है, इसलिए timestamp से पहले कुछ random bits डालकर sorted “shards” बनाने वाला hybrid भी विचार करने लायक है। reads भी अक्सर latest data पर केंद्रित होती हैं, इसलिए latest data का एक जगह होना और cache में अच्छी तरह आना उपयोगी है
    • DynamoDB जैसे key-value stores के लिए भी बहुत अच्छा है। timestamp या ISO date को prefix बनाकर composite key बनाने से यह कहीं साफ़ है, और timestamp के लिए secondary index बर्बाद करने से भी बेहतर है

  • uuid2 का उद्देश्य समझना मुश्किल है। मुझे यह भी नहीं पता था कि ऐसे और भी types हैं, और Xandr से अपना personal data हटाने का अनुरोध करते समय मैंने पहली बार uuid2 देखा था: https://news.ycombinator.com/item?id=40913915
    Wikipedia पढ़ने पर भी ठीक से समझ नहीं आता कि “सार्वभौमिक unique identifier” बनाने के बाद भी कई types क्यों रखे गए, और उनमें से कुछ को मूल रूप से PC तक track करने लायक क्यों बनाया गया था। सोचता हूँ कि MAC code का कुछ हिस्सा मिलाने से uuid2 ज़्यादा random जैसा हो जाता है, या इसकी कोई और वजह है। privacy के नज़रिए से यह भी सोचता हूँ कि बहुत ज़्यादा selectable characters वाला लंबा identifier इस्तेमाल करके duplicate होने की संभावना को व्यावहारिक रूप से खत्म क्यों नहीं किया जा सकता

    • मूल उद्देश्य Apollo distributed computing architecture में messages की पहचान करना था। UID और बाद में UUID दो dimensions के intersection को दिखाने का reversible तरीका था
      कोई भी दो machines समान दो inputs के लिए समान UID/UUID बना सकती थीं, और identified message पाने वाला पक्ष identifier को वापस उसके original components में बदल सकता था। इसे temporary messages के label के रूप में design किया गया था, इसलिए दो dimensions समय और hardware ID थे; शुरुआत में Apollo serial number, बाद में Ethernet hardware address आदि इस्तेमाल हुए
      मेरे हिसाब से confusion का बड़ा हिस्सा शुरुआती AEGIS implementation में Apollo engineers द्वारा filesystem identification के लिए “canned”, यानी static और well-known UID इस्तेमाल करना शुरू करने से आया। समय के साथ UUID का सामान्य उपयोग, जानबूझकर duplicate हो सकने वाले temporary identifiers से पूरी तरह उन canned identifiers की ओर चला गया जिनमें duplicate से बचना था, और दोनों dimensions भी random और फिर random हो गए
      इतिहास इससे भी जटिल है। Microsoft ने Windows NT के लिए MSRPC बनाने के लिए Apollo के core लोगों में से एक को hire किया, और इसी से GUID भी आया। GUID का field layout UUID से अलग है, और कई sources जो कहते हैं उसके विपरीत, यह mixed-endian नहीं है। Microsoft temporary RPC message identification GUID के अलावा COM classes, media codecs आदि जैसे लगभग हर उस चीज़ के लिए canned GUID का खूब इस्तेमाल करता है जिसे well-known identifier चाहिए। उदाहरण: https://gix.github.io/media-types/
      उसी comment thread में अपना repository दो बार link करने के लिए माफ़ी, लेकिन मैंने अपनी UUID library के README में यह इतिहास लिखना शुरू किया था और इसे फिर आगे बढ़ाना चाहिए। Apollo 1980 में शुरू हुआ था और Leach/Salz UUID RFC draft 1998 में ही आया, इसलिए modern standards में बहुत सारी बातें छूटी हुई हैं: https://github.com/okeeblow/DistorteD/blob/NEW%E2%80%85SENSA...

  • UUID v4 तो बस random byte generator है जो तय जगहों पर hyphen डालता है। इसे ज़रूर इस्तेमाल करने की जरूरत नहीं; आप खुद random bytes बना सकते हैं और space बचा सकते हैं
    गैरज़रूरी hyphens, version information जैसी चीज़ें भी कम हो जाएँगी

    • UUID एक 128-bit number है, और hyphen वाली string representation उस number को दिखाने के कई तरीकों में से सिर्फ एक है
      यह कुछ वैसा है जैसे IPv4 address 32-bit number होता है और “dot-separated four groups” उसका एक representation है। अगर आप UUID को string format समझते हैं, तो UUID की सबसे basic concept ही गलत पकड़ रहे हैं। भले ही आपको सिर्फ random identifier चाहिए हो, random UUID में “यह random के तौर पर intended है” बताने वाले छोटे flag bits होना मुझे अच्छा लगता है। जब सिर्फ एक context-less identifier मिले तो यह उपयोगी होता है
    • UUID v4, version 4 दर्शाने के लिए 4 bits को भी fixed value पर set करता है
      अलग-अलग generation methods के बीच अलग namespaces बनाना उपयोगी है या नहीं, इस पर बहस हो सकती है, लेकिन सामान्य random generator के valid UUIDv4 बनाने की संभावना सिर्फ 1/16 है। बेशक, अगर आप अपना UUID generator बनाना चाहते हैं तो bits को सही तरह set करना मामूली बात है
    • सही है, लेकिन अधिकांश developers के लिए आकर्षक बात यह है कि implementation आसान है। लगभग हर language में एक line में काम करने वाली UUID library होती है
      Go में uuid.New().String() काफी है, लेकिन crypto/rand से random data पढ़कर उसे base64 या hex में बदलने के लिए ज्यादा lines और effort चाहिए

  • MAC-based versions न इस्तेमाल करने की सलाह है। सैद्धांतिक रूप से v4 और v7 के अलावा बाकी सब पर यह लागू हो सकता है, लेकिन v1 सबसे खराब है
    v3 में भी MD5 के बुरी तरह टूट चुके होने की समस्या है

    • MD5 cryptographic hash function के रूप में “broken” है। non-cryptographic hash function के रूप में यह अभी भी पूरी तरह ठीक है

  • मुझे version 4 के अलावा details नहीं पता थीं, लेकिन सच में उपयोगी missing चीज़ शायद SHA256 data और counter इस्तेमाल करने का तरीका होगा। यह PBKDF2 जैसी form है
    यह privacy-preserving derived identifier हो सकता है, और loosely यह prove भी कर सकता है कि कोई specific UUID किसी seed से derived है

    • अगर सच में जरूरत हो तो UUIDv4 को encoding format मानकर, crypto algorithm से 122-bit output बनाइए और उसे UUID के रूप में encode कर दीजिए
      इसके अलावा, आप शायद longer output चाहेंगे
    • यह v3 जैसा है, लेकिन ऐसा रूप जिसमें hash algorithm specify किया जा सके

  • बस v7 इस्तेमाल कर लो
    अब security experts के “नहीं” कहने की बारी है

    • अगर creation date sensitive information हो सकती है या UUID पूरी तरह unguessable होना चाहिए, तो v4 इस्तेमाल करें। बाकी मामलों में v7 इस्तेमाल करें
    • UUID और ULID में मुझे हमेशा जो कमी लगी, वह यह है कि मेरी जानकारी में इन्हें deterministically generate करने का कोई अच्छा तरीका नहीं है
      कई use cases में data को दोबारा process करने पर भी समान ID generate कर पाना बहुत उपयोगी होता है, लेकिन इसे हासिल करने का कोई standard तरीका मुझे नहीं पता
    • समझ नहीं आता कि security-related issues को इतना हल्के में क्यों लिया जाता है