UUID टक्कर [बंद]

33

क्या किसी ने UUID टकराव की संभावना पर कोई वास्तविक शोध किया है, विशेष रूप से संस्करण 4 (यादृच्छिक) UUIDs के साथ, यह देखते हुए कि हम जिस यादृच्छिक संख्या जनरेटर का उपयोग करते हैं वह वास्तव में यादृच्छिक नहीं है और हमारे पास समान कोड चलाने वाली दर्जनों या सैकड़ों समान मशीनें हो सकती हैं। UUIDs उत्पन्न करना

मेरे सह-कार्यकर्ता UUID टक्कर के लिए परीक्षण को समय की पूरी बर्बादी मानते हैं, लेकिन मैं हमेशा डेटाबेस से डुप्लिकेट कुंजी अपवाद को पकड़ने और नए UUID के साथ फिर से प्रयास करने के लिए कोड में रखता हूं। लेकिन यह समस्या को हल करने के लिए नहीं जा रहा है अगर UUID दूसरी प्रक्रिया से आता है और एक वास्तविक वस्तु को संदर्भित करता है।

random uuid

— पॉल टॉम्बलिन
स्रोत

4

स्टैक ओवरफ्लो पर पहले से ही इस सवाल का जवाब दिया गया था: stackoverflow.com/questions/3038023/… , जैसा कि मूल Google खोज दिखाता है: google.com/search?q=uuid+collision

— Arseni Mourzenko

3

यह प्रश्न SQL * सर्वर में उपयोग किए जाने वाले विशिष्ट एल्गोरिदम के बारे में है, जो निश्चित रूप से संस्करण 4 (यादृच्छिक) नहीं है। मैं विशेष रूप से संस्करण 4 के बारे में पूछ रहा हूं।

— पॉल टॉम्बलिन

क्या आप कह रहे हैं कि SQL Server का कार्यान्‍वयन NEWID()यादृच्छिक नहीं है? यदि हां, तो क्या आपके पास ऐसा दावा करने के लिए कोई स्रोत है? इसका आउटपुट स्पष्ट रूप से v4 UUIDs की तरह दिखता है। NEWSEQUENTIALID()निश्चित रूप से पूरी तरह से यादृच्छिक नहीं है, लेकिन इसका उद्देश्य है : यूयूआईडी उत्पन्न करना जो अच्छी तरह से काम करता है (साथ ही साथ यूयूआईडीएस, कम से कम) सूचकांक कुंजी के रूप में।

— एक CVn

1

मैं लिंक किए गए प्रश्न के उत्तर से जा रहा हूं, जिसमें कहा गया है कि NEWID () में मैक पते के कुछ टुकड़े हैं, जो इसे V1 या V2 UUID बनाता है, न कि V4।

— पॉल टॉम्बलिन

2

यह प्रश्न ऑफ़-टॉपिक प्रतीत होता है क्योंकि यह कुछ ऐसा है जिसके बारे में पहले से ही इंटरनेट पर, किताबों में और विशेष रूप से StackOverflow पर

18

विकिपीडिया में कुछ विवरण हैं:

http://en.wikipedia.org/wiki/Universally_unique_identifier

http://en.wikipedia.org/wiki/Universally_unique_identifier#Random_UUID_probability_of_duplicates

लेकिन संभावना केवल तभी होती है जब बिट पूरी तरह से यादृच्छिक होते हैं। हालाँकि, अन्य उत्तर में लिंक किया गया RFC http://tools.ietf.org/html/rfc4122#page-14 संस्करण 4 के लिए इसे परिभाषित करता है:

"4.4। [...] संस्करण 4 यूयूआईडी का अर्थ है वास्तव में यादृच्छिक या छद्म यादृच्छिक संख्याओं से यूयूआईडी उत्पन्न करने के लिए। [...] सभी अन्य बिट्स को यादृच्छिक रूप से (या छद्म-यादृच्छिक रूप से) चुने गए मानों के लिए सेट करें।"

यह बहुत अधिक क्वांटम शोर का उपयोग कर एक हार्डवेयर डिवाइस के लिए xkcd यादृच्छिक जनरेटर http://xkcd.com/221/ से कुछ भी अनुमति देता है । RFC में सुरक्षा संबंधी विचार:

6. "विभिन्न प्रकार के मेजबानों पर UUIDs बनाने वाले वितरित अनुप्रयोगों को सभी मेजबानों पर यादृच्छिक संख्या स्रोत पर भरोसा करने के लिए तैयार होना चाहिए। यदि यह संभव नहीं है, तो नाम स्थान संस्करण का उपयोग किया जाना चाहिए।"

मैंने इसे इस रूप में पढ़ा: आप अपने दम पर हैं। आप अपने स्वयं के अनुप्रयोग के भीतर अपने यादृच्छिक जनरेटर के लिए जिम्मेदार हैं, लेकिन यह और कुछ भी विश्वास पर आधारित है। यदि आप अपनी पसंद के यादृच्छिक जनरेटर को सही ढंग से समझने और उपयोग करने की अपनी क्षमता पर भरोसा नहीं करते हैं, तो टकरावों की जांच करना वास्तव में एक अच्छा विचार है। यदि आप अन्य प्रक्रियाओं के प्रोग्रामर पर भरोसा नहीं करते हैं, तो टकराव की जांच करें या एक अलग यूयूआईडी संस्करण का उपयोग करें।

— सुरक्षित
स्रोत

11

यदि टक्कर होती है तो आपको निश्चित रूप से पता लगाना चाहिए, और यदि ऐसा होता है तो आपके आवेदन को एक अपवाद फेंक देना चाहिए। उदाहरण के लिए, यदि UUID का उपयोग डेटाबेस में प्राथमिक कुंजी के रूप में किया जाता है, तो डेटाबेस को एक टकराने वाली आईडी डालते समय एक त्रुटि फेंकनी चाहिए।

हालाँकि, मुझे विश्वास होगा कि टक्कर के मामले में एक नया यूयूआईडी बनाने के लिए कोड लिखना और फिर से समय बर्बाद करने की कोशिश करना। एक टक्कर होने की संभावना इतनी कम है कि एक अपवाद को फेंकना इसके साथ निपटने का एक बिल्कुल उचित तरीका होगा।

याद रखें, यह न केवल कोड लिखने के लिए आपके खुद के समय की बर्बादी है, बल्कि यह कोड को और अधिक जटिल बनाता है, जिससे अगले व्यक्ति के लिए पढ़ना अधिक मुश्किल हो जाता है, लगभग कोई लाभ नहीं।

— पीट
स्रोत

2

आपका UUID केवल आपके यादृच्छिक जनरेटर के रूप में अच्छा है। बहुत ( बहुत ) गरीबों के साथ न केवल टकराव होगा, बल्कि अपरिहार्य होगा। उन्होंने कहा कि शायद पीढ़ी के समय में डुप्लिकेट के लिए जाँच करना वास्तव में बहुत मुश्किल होगा, लेकिन यह उम्मीद करना कि स्थिति हो सकती है और मेरी राय में, इतना पूछने के लिए नहीं है। कुछ डोमेन में (उदाहरण के लिए स्वास्थ्य देखभाल) मुझे लगता है कि कोड होना आवश्यक है जो ऐसी स्थितियों को पकड़ते हैं (शायद डेटाबेस में टकराव का पता लगाने के रूप में)। आपको आश्चर्य होगा कि मैंने डिबगिंग स्थितियों में कितना समय बिताया है जो कभी नहीं होता है।

— न्यूटॉपियन

1

मुझे लगता है कि मैंने खुद को स्पष्ट नहीं किया। मैंने उत्तर को अधिक स्पष्ट होने के लिए अद्यतन किया है।

— पीट

7

यह एक बहुत अच्छा सवाल है। मुझे विश्वास नहीं है कि इसे हर जगह यूयूआईडी का उपयोग करने के लिए पर्याप्त रूप से माना जाता है। मुझे कोई ठोस शोध नहीं मिला है।

एक सुझाव: यहां बहुत सावधानी से चलें, और अपनी क्रिप्टोग्राफी को अच्छी तरह से जानें। यदि आप 128-बिट UUID का उपयोग करते हैं, तो 'जन्मदिन का प्रभाव' हमें बताता है कि आपके द्वारा लगभग 2 ^ 64 कुंजी उत्पन्न करने के बाद टक्कर की संभावना है, बशर्ते आपके पास प्रत्येक कुंजी में 128 बिट्स एन्ट्रापी हों ।

वास्तव में यह सुनिश्चित करना मुश्किल है कि यह मामला है। ट्रू रैंडमनेस (a) रेडियोधर्मी क्षय (b) रैंडम बैकग्राउंड रेडियो शोर से उत्पन्न हो सकता है, अक्सर दूषित जब तक आप सावधान (c) उपयुक्त रूप से चुने हुए इलेक्ट्रॉनिक शोर, जैसे कि रिवर्स-बायस्ड जेनर डायोड से नहीं लेते। (मैंने आखिरी के साथ खेला है, और यह आकर्षण की तरह काम करता है, BTW)।

जब तक उपयोगकर्ता ने 2 (64) (लगभग 10 ^ 19) कुंजियों के पास कुछ उत्पन्न नहीं किया है, और मैंने उन सभी को एक दूसरे के खिलाफ चेक किया है, जब तक कि "मैंने उपयोग के एक वर्ष में ऐसा नहीं देखा है" जैसे घोषणाओं पर भरोसा नहीं करेगा। गैर तुच्छ व्यायाम।

समस्या यह है। मान लें कि आपके पास एंट्रॉपी के सिर्फ 100 बिट्स हैं, जब अन्य सभी चाबियों के खिलाफ अपनी कुंजियों की तुलना करना हर किसी के लिए एक सामान्य कीस्पेस में उत्पन्न होता है। आप लगभग 2 ^ 50 में टकराव देखना शुरू कर देंगे। के बारे में 10 ^ 15 चाबियाँ। टक्कर देखने की आपकी संभावना यदि आपने अपने डेटाबेस को केवल 1000 बिलियन कुंजी के साथ आबाद किया है, तब भी आप नगण्य हैं। और अगर आप जांच नहीं करते हैं, तो आपको बाद में अप्रत्याशित त्रुटियां मिलेंगी जो आपके पेटा-पंक्ति आकार डेटाबेस में रेंगती हैं। यह कठिन काट सकता है।

बहुत तथ्य यह है कि ऐसे यूयूआईडी उत्पन्न करने के लिए कई दृष्टिकोण हैं, चिंता के एक क्षणिक ऐंठन का कारण होना चाहिए। जब आपको पता चलता है कि कुछ जनरेटर टाइप 4 यूयूआईडी के लिए पर्याप्त एन्ट्रापी के साथ 'सही मायने में यादृच्छिक' प्रक्रियाओं का उपयोग करते हैं, तो आपको अत्यधिक चिंतित होना चाहिए जब तक कि आपने जनरेटर की एन्ट्रापी सामग्री की सावधानीपूर्वक जांच नहीं की हो। (ज्यादातर लोग ऐसा नहीं करेंगे, या यह भी जानते हैं कि आप कैसे हो सकते हैं; आप डाईहार्डर सुइट से शुरू कर सकते हैं)। सही यादृच्छिक संख्या पीढ़ी के साथ छद्म आयामी संख्या पीढ़ी को भ्रमित न करें।

यह महत्वपूर्ण है कि आप महसूस करते हैं कि आपके द्वारा लगाई गई एन्ट्रापी आपके पास है, और क्रिप्टोग्राफिक फ़ंक्शन को लागू करके कुंजी को उल्टा करने से एन्ट्रापी में कोई परिवर्तन नहीं होता है। यह सहज रूप से स्पष्ट नहीं हो सकता है कि यदि मेरे पूरे स्थान में अंक 0 और 1 शामिल हैं, तो एन्ट्रापी सामग्री निम्नलिखित दो तारों के समान है, बशर्ते वे केवल दो विकल्प हों: "यह वास्तव में जटिल स्ट्रिंग है 2932729382832 * ! @@ # & ^% $$), m} "और" और अब समतुल्य सम्पत्ति की प्राप्ति के लिए "। अभी भी दो विकल्प हैं।

यादृच्छिकता सही पाने के लिए मुश्किल है, और बस विश्वास है कि "विशेषज्ञों ने इसे देखा है, इसलिए यह ठीक है" पर्याप्त नहीं हो सकता है। विशेषज्ञ क्रिप्टोग्राफर (और इनमें से कुछ ऐसे हैं जो वास्तव में कुशल हैं) सबसे पहले स्वीकार करते हैं कि वे अक्सर इसे गलत पाते हैं। हमने हार्दिक, डिगिनोटार, आदि पर भरोसा किया।

मुझे लगता है कि पॉल टॉम्बलिन उचित सावधानी बरत रहा है। मेरा 2 सी।

— user199506
स्रोत

6

आपके पास समस्या यह है कि यदि आप "रैंडम नंबर जनरेटर" का उपयोग करते हैं और आपको नहीं पता कि जनरेटर कितना यादृच्छिक है, तो टक्कर की संभावना वास्तव में अज्ञात है। यदि यादृच्छिक संख्या जनरेटर को किसी तरह से संबंधित किया जाता है, तो टकराव की संभावना नाटकीय रूप से बढ़ सकती है - संभवतः कई, कई आदेश या परिमाण।

यहां तक कि अगर आपके पास टक्कर की बहुत कम संभावना है, तो आपके पास एक मूलभूत समस्या है: संभावना 0 नहीं है। इसका मतलब है कि टक्कर अंततः होगी, वे बस बहुत बार नहीं होंगे।

जितनी बार आप UUIDs का उपयोग करते हैं उतनी ही जल्दी उत्पन्न होते हैं और टकराने की संभावना देखी जाती है। (प्रति वर्ष 1 जनरेट करने का मतलब है कि प्रति सेकंड एक मिलियन उत्पन्न करने की तुलना में एक लंबा प्रतीक्षा समय, अन्य सभी चीजें बराबर हो रही हैं)।

यदि वह संभावना परिमित है, अज्ञात है, और आप बहुत सारे यूयूआईडी का उपयोग करते हैं तो आपको टकराव के परिणामों पर विचार करने की आवश्यकता है। यदि अपवाद को फेंकना और व्यावसायिक अनुप्रयोग बंद करना स्वीकार्य नहीं है, तो ऐसा न करें! (मेरे सिर के ऊपर के उदाहरण: "लाइब्रेरी चेकइन को अपडेट करने के बीच में वेब सर्वर को बंद करना ठीक है ... यह अक्सर नहीं होगा" और "बीच में पेरोल सिस्टम को बंद करना ठीक है" वेतन रन करना "। ये निर्णय चाल को सीमित करने वाला करियर हो सकता है।"

आपके आवेदन के आधार पर आपके पास फिर से एक बदतर मामला हो सकता है। यदि आप एक UUID की उपस्थिति के लिए परीक्षण करते हैं (यानी, एक लुकअप करें) और फिर एक नया बनाएं यदि एक पहले से ही नहीं है - जो कि एक सामान्य पर्याप्त प्रकार की चीज़ है - तो आप पा सकते हैं कि आप रिकॉर्ड लिंक कर रहे हैं या संबंध बना रहे हैं , जब वास्तव में आप एक UUID के माध्यम से 2 चीजों को हुक कर रहे हैं, जो कि हुक नहीं होना चाहिए। यह कुछ ऐसा है जहां एक अपवाद को फेंकने से कुछ हल नहीं होगा और आपके पास एक undetectable मेस कहीं बना होगा। यह इस तरह की बात है जिससे सूचना का रिसाव होता है और यह बहुत शर्मनाक हो सकता है। (पूर्व: अपने बैंक में प्रवेश करें और पाएं कि आप किसी के खाते की शेष राशि देख सकते हैं! बुरा!)

सारांश: आपको अपने यूयूआईडी का उपयोग करने के तरीके, और टकराव के परिणामों पर विचार करने की आवश्यकता है। यह निर्धारित करता है कि क्या आपको टकरावों का पता लगाने और बचने के लिए ध्यान रखना चाहिए, टकराव की स्थिति में कुछ सरल कार्रवाई करें, या कुछ भी न करें। एक सरल, एकल, एक-फिट-सभी समाधान कुछ परिस्थितियों में अनुचित होने की संभावना है।

— quickly_now
स्रोत

2

"संभावना की (टक्कर की) 0 नहीं है" किसी भी परिमित लंबाई के अनुक्रम में यह गुण है। यहां तक कि एक पूरी तरह से यादृच्छिक v4 UUID के साथ, एक बार जब आप 2 ^ 122 अद्वितीय UUIDs (128 बिट्स माइनस 4 बिट्स वर्जन माइनस 2 आरक्षित बिट्स) उत्पन्न कर लेते हैं, तो आप जो भी जेनरेट करते हैं वह एक टक्कर होने की गारंटी है। सबसे अधिक संभावना है कि आप इससे जल्द ही टकरा जाएंगे। बड़ा सवाल यह है कि 5e36 repetitions की तरह कुछ के बाद एक टकराव एक मुद्दा है, और इसका जवाब आम तौर पर नहीं दिया जा सकता है (हालांकि प्रत्येक विशिष्ट मामले में इसका उत्तर देना संभव है), जैसे आप सारांश में कहते हैं।

— एक CVn

बेशक। यह स्पष्ट (लेकिन अभी भी दोहराता भालू) का एक बयान था। मुद्दा यह है कि यादृच्छिक संख्या जनरेटर के लिए कितना सहसंबंध है। इससे टकराव की संभावना काफी बढ़ सकती है (2 ^ बड़े), लेकिन आप कितना कुछ जानते हैं जब तक आप बहुत सारे खुदाई, शोध या गणना नहीं करते। टक्कर की संभावना मानते हुए सबसे अच्छा मूल्य शायद विवेकपूर्ण है की तुलना में काफी खराब है। उसके बाद ... आपको फिर परिणामों पर विचार करने की आवश्यकता है।

— जल्दी_नौज

0

इसमें दो मुद्दे शामिल हैं:

उपयोग किए जाने वाले यादृच्छिक संख्या जनरेटर की गुणवत्ता।
यूयूआईडी की राशि जो उत्पन्न की जा सकती है।

एक "यादृच्छिक" UUID में 122 यादृच्छिक बिट्स हैं। पूर्ण यादृच्छिकता मानकर, आप लगभग 2 ^ 61 उत्पन्न UUIDs (कि 2 ^ 122 का वर्गमूल) में पहली टक्कर की उम्मीद कर सकते हैं। यदि इस पृथ्वी पर हर व्यक्ति प्रति सेकंड एक यूयूआईडी उत्पन्न करता है, तो वह प्रति वर्ष 10,000,000,000 * 365 * 24 * 60 * 60 = 315360000000000000 यूयूआईडी है, जो 2 ^ 58 के काफी करीब है। यानी कुछ सालों के बाद आपको पहली टक्कर मिलेगी। जब तक आपका आवेदन उन नंबरों के पास कहीं भी नहीं मिलता है, तब तक आप यह सुनिश्चित कर सकते हैं कि यदि आपके रैंडम जनरेटर सभ्य गुणवत्ता के हैं तो आपको टक्कर नहीं मिलेगी।

यादृच्छिक संख्या जनरेटर के बारे में बात करना: यदि आप मानक सी लाइब्रेरी जनरेटर (सीधे, अप्रत्यक्ष या समान जनरेटर) का उपयोग करते हैं, तो संभवत: उन्हें समय के साथ सीडिंग करते हुए, आपको स्केच किया जाता है। ये टकराव से बचने के लिए पर्याप्त एन्ट्रापी पर नहीं खींच सकते। हालाँकि, यदि आप लिनक्स पर हैं, तो केवल 16 बाइट्स डेटा पढ़ें /dev/urandom: यह एक एंट्रॉपी पूल पर खींचता है जो कर्नेल द्वारा उभारा जाता है, जिसमें कुछ वास्तविक यादृच्छिक घटनाओं तक पहुंच होती है। जब तक आप आमतौर पर बूट अनुक्रम में वास्तव में बहुत जल्दी यूयूआईडी उत्पन्न /dev/urandomकरते हैं, एक सच्चे यादृच्छिक स्रोत की तरह व्यवहार करना चाहिए।

— cmaster
स्रोत

-1

मैंने 10 मिलियन यूयूआईडी-एस उत्पन्न करने वाले एक काफी सरल (ब्रूट फोर्स) प्रोग्राम का उपयोग करके एक बार इसका परीक्षण किया है और मैंने टक्कर का अनुभव नहीं किया है।

UUID आरएफसी का कहना है कि UUID बस (छद्म) यादृच्छिक संख्या का एक समूह नहीं है।

— xea
स्रोत

1

संस्करण 4, जो एक मैं के बारे में पूछ रहा हूँ, बहुत ज्यादा यादृच्छिक संख्याओं का एक गुच्छा है, 6 बिट्स को छोड़कर जो उन सभी में बिल्कुल समान होगा।

— पॉल टॉम्बलिन

8

10 मिलियन भी बाल्टी में एक बूंद नहीं है। टकराव की संभावना 3E30 में केवल 1 है। यदि आपको एक मिल गया है, तो मैंने आपको सलाह दी है कि आप हर लॉटरी में टिकट खरीद सकते हैं और खरीद सकते हैं!

— रॉस पैटरसन

@RossPatterson, जो मैं विशेष रूप से सोच रहा था कि अगर आपको एक ही हार्डवेयर पर सटीक एक ही पीडो-रैंडम एल्गोरिथ्म का उपयोग करके कई सौ कंप्यूटर मिले हैं, तो नाटकीय रूप से टकराव की संभावना बढ़ जाती है। मुझे शक है।

— पॉल टॉम्बलिन

1

@ पाओल - मैंने केवल तभी सोचा होगा यदि प्रारंभिक बोने की प्रक्रिया में अपर्याप्त एन्ट्रॉपी है - उदाहरण के लिए यदि बीज केवल दिन के समय से उत्पन्न होता है, और आपकी सभी मशीनें उसी पल के करीब शुरू हुईं। मुझे बहुत संदेह है कि बोना कमजोर है - यह भी संभव है कि हार्डवेयर सीरियल नंबर का उपयोग किया जाता है, जो प्रत्येक मशीन के लिए निश्चित रूप से अद्वितीय होगा।

— स्टीव ३४

1

काश, बोना बहुत कमजोर हो सकता है। लिनक्स सिस्टम अत्यधिक यादृच्छिक स्रोतों (डिवाइस ड्राइवर गतिविधि, आदि ) से PRNG बोने के शौकीन हैं , लेकिन अन्य वातावरणों में, मानक टाइमस्टैम्प का उपयोग करने के लिए मानक है, जो निकट समय-सिंक में पर्याप्त मशीनों के साथ एक समस्या हो सकती है।

— रॉस पैटरसन