मेरे मामले में अधिकांश आईडी बड़ी संख्या में मोबाइल क्लाइंट के भीतर उत्पन्न होंगे, सर्वरों के सीमित सेट के भीतर नहीं। मुझे आश्चर्य है कि क्या इस मामले में कोई उचित चिंता है।
यह मेरे लिए बहुत खराब वास्तुकला की तरह लगता है। क्या आप दो स्तरीय वास्तुकला का उपयोग कर रहे हैं? मोबाइल ग्राहकों की डीबी तक सीधी पहुंच क्यों होगी? क्या आप वाकई नेटवर्क-आधारित सुरक्षा पर भरोसा करना चाहते हैं?
वैसे भी, टक्कर की संभावना के बारे में कुछ विचार-विमर्श:
न तो UUID और न ही ObjectId अपने विशाल आकार पर भरोसा करते हैं, यानी दोनों यादृच्छिक संख्या नहीं हैं, लेकिन वे एक ऐसी योजना का पालन करते हैं जो व्यवस्थित रूप से टकराव की संभावना को कम करने की कोशिश करती है। ObjectIds के मामले में, उनकी संरचना है:
- यूनिक्स युग के बाद से 4 बाइट सेकंड
- 3 बाइट मशीन आईडी
- 2 बाइट प्रोसेस आईडी
- 3 बाइट काउंटर
इसका मतलब यह है कि, यूयूआईडी के विपरीत, ऑब्जेक्ट आईडी मोनोटोनिक (एक सेकंड के भीतर छोड़कर) हैं, जो शायद उनकी सबसे महत्वपूर्ण संपत्ति है। मोनोटोनिक इंडेक्स बी-ट्री को अधिक कुशलता से भरने का कारण बनता है, यह आईडी द्वारा पेजिंग की अनुमति देता है और आपके कर्सर को स्थिर बनाने के लिए आईडी द्वारा 'डिफ़ॉल्ट सॉर्ट' की अनुमति देता है, और निश्चित रूप से, वे एक आसान-से-निकालने वाला टाइमस्टैम्प लेते हैं। ये वे अनुकूलन हैं जिनके बारे में आपको पता होना चाहिए, और ये बहुत बड़े हो सकते हैं।
जैसा कि आप अन्य 3 घटकों की संरचना से देख सकते हैं, यदि आप एक ही प्रक्रिया पर> 1k इंसर्ट/एस कर रहे हैं तो टकराव बहुत संभव हो जाता है (वास्तव में संभव नहीं है, सर्वर से भी नहीं), या यदि मशीनों की संख्या बढ़ती है पिछले लगभग 10 (जन्मदिन की समस्या देखें), या यदि एक मशीन पर प्रक्रियाओं की संख्या बहुत बड़ी हो जाती है (तो फिर, वे यादृच्छिक संख्या नहीं हैं, लेकिन वे मशीन पर वास्तव में अद्वितीय हैं, लेकिन उन्हें दो बाइट्स तक छोटा किया जाना चाहिए )।
स्वाभाविक रूप से, टकराव होने के लिए, उन्हें सभी . में मेल खाना चाहिए इन पहलुओं, इसलिए भले ही दो मशीनों में एक ही मशीन हैश हो, फिर भी क्लाइंट को उसी काउंटर वैल्यू के साथ ठीक उसी सेकेंड और एक ही प्रक्रिया आईडी में डालने की आवश्यकता होगी, लेकिन हां, ये मान टकरा सकते हैं।
