मोंगो में यूयूआईडी का उपयोग करना निश्चित रूप से संभव है और यथोचित रूप से समर्थित है। उदाहरण के लिए, Mongo डॉक्स UUIDs को _id के सामान्य विकल्पों में से एक के रूप में सूचीबद्ध करता है फ़ील्ड.
विचारों
- प्रदर्शन - जैसा कि अन्य उत्तरों में उल्लेख किया गया है, बेंचमार्क दिखाते हैं कि यूयूआईडी इंसर्ट के प्रदर्शन में गिरावट का कारण बनते हैं। सबसे खराब स्थिति में (एक संग्रह में 10M से 20M डॉक्स तक जा रहा है) उनके पास लगभग ~ 2-3x धीमा है - प्रति सेकंड 2,000 (UUID) और 7,500 (ऑब्जेक्टआईडी) डॉक्स डालने के बीच का अंतर। यह एक बड़ा अंतर है लेकिन इसका महत्व पूरी तरह से आपके उपयोग के मामले पर निर्भर करता है। क्या आप एक बार में लाखों डॉक्स डालने वाले बैच होंगे? अधिकांश ऐप्स के लिए मैंने अलग-अलग दस्तावेज़ डालने का सामान्य मामला बनाया है। वही बेंचमार्क दिखाते हैं कि, उस उपयोग पैटर्न के लिए, अंतर बहुत है छोटा (6,250 -बनाम- 7,500; ~ 20%)। महत्वहीन नहीं.. लेकिन धरती को तोड़ने वाला भी नहीं.
- पोर्टेबिलिटी - कई अन्य डीबी प्लेटफार्मों में अच्छा यूयूआईडी समर्थन है, इसलिए पोर्टेबिलिटी में सुधार होगा। वैकल्पिक रूप से, चूंकि यूयूआईडी बड़े (अधिक बिट्स) हैं, इसलिए ऑब्जेक्ट आईडी को यूयूआईडी के "आकार" में दोबारा पैक करना संभव है। यह तरीका डायरेक्ट पोर्टेबिलिटी जितना अच्छा नहीं है लेकिन यह आपको मौजूदा ऑब्जेक्ट आईडी और यूयूआईडी के बीच "मैप" करने का एक तरीका देता है।
- विकेंद्रीकरण - यूयूआईडी के बड़े विक्रय बिंदुओं में से एक यह है कि वे सार्वभौमिक रूप से अद्वितीय हैं। यह उन्हें विकेन्द्रीकृत फैशन में कहीं भी उत्पन्न करने के लिए व्यावहारिक बनाता है (उदाहरण के लिए, एक ऑटो-इंक्रीमेंटिंग वैल्यू के विपरीत, जिसके लिए "अगला" मान निर्धारित करने के लिए सत्य के केंद्रीकृत स्रोत की आवश्यकता होती है)। बेशक, मोंगो ऑब्जेक्ट आईडी भी इस लाभ का दावा करते हैं। अंतर यह है कि, यूयूआईडी 15+ वर्ष पुराने मानक पर आधारित हैं और सभी प्लेटफॉर्म, भाषाओं आदि पर (लगभग?) समर्थित हैं। यह उन्हें बहुत उपयोगी बनाता है यदि आपको कभी भी संस्थाएं बनाने की आवश्यकता होती है (या विशेष रूप से, संबंधित के सेट संस्थाओं) डेटाबेस के साथ बातचीत किए बिना, असंबद्ध प्रणालियों में। आप आईडी और विदेशी कुंजियों के साथ एक डेटासेट बना सकते हैं, फिर भविष्य में किसी बिंदु पर बिना किसी विरोध के पूरे ग्राफ को डेटाबेस में लिख सकते हैं। हालांकि यह Mongo ObjectIDs के साथ भी संभव है, उन्हें उत्पन्न करने के लिए कोड ढूंढना/प्रारूप के साथ काम करना अक्सर कठिन होगा।
सुधार
कुछ अन्य उत्तरों के विपरीत:
- यूयूआईडी के पास मूल मोंगो समर्थन है - आप
UUID(). का उपयोग कर सकते हैं Mongo Shell में ठीक उसी तरह काम करता है जैसे आपObjectID(). का इस्तेमाल करते हैं; UUID स्ट्रिंग को समतुल्य BSON ऑब्जेक्ट में बदलने के लिए। - यूयूआईडी विशेष रूप से बड़े नहीं होते हैं - बाइनरी उपप्रकार
0x04. का उपयोग करके एन्कोड किए जाने पर ObjectIDs के लिए 96 बिट्स की तुलना में वे 128 बिट्स हैं। (यदि स्ट्रिंग के रूप में एन्कोड किया गया है तो वे करेंगे लगभग 288 बिट्स लेते हुए, बहुत बेकार हो।) - यूयूआईडी में टाइमस्टैम्प शामिल हो सकता है - विशेष रूप से, UUIDv1 ऑब्जेक्ट आईडी में 32 बिट्स की तुलना में 60 बिट सटीक के साथ टाइमस्टैम्प को एन्कोड करता है। यह परिमाण के 6 से अधिक आदेश अधिक सटीक है, इसलिए सेकंड के बजाय नैनो-सेकंड। यह वास्तव में मोंगो/जेएस दिनांक ऑब्जेक्ट समर्थन की तुलना में अधिक सटीकता के साथ टाइमस्टैम्प बनाने का एक अच्छा तरीका हो सकता है, हालांकि...
- बिल्ड इन
UUID()फ़ंक्शन केवल v4 (यादृच्छिक) यूयूआईडी उत्पन्न करता है, इसलिए इसका लाभ उठाने के लिए, आपको आईडी बनाने के लिए अपने ऐप या मोंगो ड्राइवर पर निर्भर रहना होगा। - ऑब्जेक्ट आईडी के विपरीत, जिस तरह से यूयूआईडी को खंडित किया जाता है, टाइमस्टैम्प आपको एक प्राकृतिक क्रम नहीं देता है। यह आपके उपयोग के मामले के आधार पर अच्छा या बुरा हो सकता है। (नए मानक इसे बदल सकते हैं; नीचे 2021 का अपडेट देखें।)
- अपनी आईडी में टाइमस्टैम्प शामिल करना कभी-कभी एक बुरा विचार होता है। आप कहीं भी एक आईडी उजागर होने पर दस्तावेजों के बनाए गए समय को लीक कर देते हैं। (बेशक ऑब्जेक्ट आईडी भी टाइमस्टैम्प को एन्कोड करते हैं, इसलिए यह उनके लिए भी आंशिक रूप से सच है।)
- यदि आप (विशिष्ट अनुरूप) v1 UUIDs के साथ ऐसा करते हैं, तो आप सर्वर MAC पते का भी भाग एन्कोडिंग कर रहे हैं, जो संभावित रूप से हो सकता है मशीन की पहचान के लिए इस्तेमाल किया जा सकता है। शायद अधिकांश प्रणालियों के लिए कोई समस्या नहीं है, लेकिन आदर्श भी नहीं है। (नए मानक इसे बदल सकते हैं; नीचे 2021 का अपडेट देखें।)
- बिल्ड इन
निष्कर्ष
यदि आप अलगाव में अपने मोंगो डीबी के बारे में सोचते हैं, तो ऑब्जेक्ट आईडी स्पष्ट विकल्प हैं। वे बॉक्स से बाहर अच्छी तरह से काम करते हैं और पूरी तरह से सक्षम डिफ़ॉल्ट हैं। इसके बजाय UUID का उपयोग करता है कुछ घर्षण जोड़ें, दोनों मूल्यों के साथ काम करते समय (बाइनरी प्रकारों में बदलने की आवश्यकता, आदि) और प्रदर्शन के संदर्भ में। क्या यह मामूली असुविधा एक मानकीकृत आईडी प्रारूप के लायक है, यह वास्तव में पोर्टेबिलिटी और आपके वास्तुशिल्प विकल्पों पर आपके द्वारा दिए गए महत्व पर निर्भर करता है।
क्या आप विभिन्न डेटाबेस प्लेटफॉर्म के बीच डेटा सिंक कर रहे होंगे? क्या आप भविष्य में अपने डेटा को किसी दूसरे प्लेटफॉर्म पर माइग्रेट करेंगे? क्या आपको बाहर आईडी जनरेट करने की आवश्यकता है डेटाबेस, अन्य सिस्टम में या ब्राउज़र में? यदि अभी नहीं तो भविष्य में किसी बिंदु पर? UUIDs परेशानी के लायक हो सकते हैं।
अगस्त 2021 अपडेट
आईईएफटी ने हाल ही में यूयूआईडी विनिर्देश के लिए एक मसौदा अद्यतन प्रकाशित किया है जो प्रारूप के कुछ नए संस्करण पेश करेगा।
विशेष रूप से, UUIDv6 और UUIDv7 UUIDv1 पर आधारित हैं, लेकिन टाइमस्टैम्प विखंडू को फ्लिप करें ताकि बिट्स को सबसे महत्वपूर्ण से कम से कम महत्वपूर्ण तक व्यवस्थित किया जा सके। यह परिणामी मूल्यों को एक प्राकृतिक क्रम देता है जो (अधिक या कम) उस क्रम को दर्शाता है जिसमें वे बनाए गए थे। नए संस्करण v1 UUIDs की लंबे समय से चली आ रही आलोचना को संबोधित करते हुए सर्वर MAC पते से प्राप्त डेटा को भी बाहर कर देते हैं।
हालांकि इन बदलावों को लागू होने में समय लगेगा लेकिन (आईएमएचओ) ये काफी आधुनिकीकरण करते हैं और प्रारूप में सुधार करते हैं।
