क्या MongoDB में दस्तावेज़ों के लिए कस्टम _id का उपयोग करने के कोई लाभ हैं?

ObjectId . का उपयोग करने के लाभ रों:

• ऑब्जेक्ट आईडी टकराव से बचने में बहुत अच्छे हैं। अगर आप अपना खुद का _id जनरेट करते हैं बेतरतीब ढंग से या समवर्ती रूप से, तो आपको टकराव के जोखिम को स्वयं प्रबंधित करने की आवश्यकता है।

• ObjectIds में उनके निर्माण का समय होता है। दस्तावेज़ की निर्माण तिथि को बनाए रखने और कालानुक्रमिक रूप से दस्तावेज़ों को क्रमबद्ध करने का यह एक सस्ता और आसान तरीका हो सकता है। (दूसरी ओर, यदि आप किसी दस्तावेज़ की निर्माण तिथि को उजागर/लीक नहीं करना चाहते हैं, तो आपको उसकी ObjectId को उजागर नहीं करना चाहिए!)

nanoid मॉड्यूल आपको शॉर्ट रैंडम आईडी बनाने में मदद कर सकता है। वे एक कैलकुलेटर भी उपलब्ध कराते हैं जो आपको एक अच्छी आईडी लंबाई चुनने में मदद कर सकता है, यह इस बात पर निर्भर करता है कि आप हर घंटे कितने दस्तावेज़/आईडी बना रहे हैं।

वैकल्पिक रूप से, मैंने mongoose-generate-unique-key लिखा था। बहुत . उत्पन्न करने के लिए लघु यादृच्छिक आईडी (बशर्ते आप नेवला पुस्तकालय का उपयोग कर रहे हों)।

साझाकरण रणनीतियां

मैं इस बारे में विशेषज्ञ होने का दावा नहीं करूंगा कि डेटा को कैसे बेहतर तरीके से शार्प किया जाए, लेकिन यहां कुछ स्थितियां हैं जिन पर हम विचार कर सकते हैं:

1. एक खगोलीय वेधशाला या कण त्वरक प्रति सेकंड गीगाबाइट डेटा को संभालता है। जब किसी दिलचस्प घटना का पता चलता है, तो वे बड़ी मात्रा में डेटा संग्रहीत करना . चाह सकते हैं कुछ ही सेकंड में। इस मामले में, वे संभवतः सभी शार्क में दस्तावेज़ों का समान वितरण चाहते हैं, ताकि प्रत्येक शार्क डेटा को संग्रहीत करने के लिए समान रूप से कड़ी मेहनत कर रही हो, और कोई भी शार्ड अभिभूत नहीं होगा।

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

3. आपके पास बड़ी मात्रा में डेटा वाला एक सोशल मीडिया ऐप है, लेकिन इस बार कई अलग-अलग उपयोगकर्ता कई हल्की क्वेरी कर रहे हैं मुख्य रूप से उनके अपने डेटा, या उनके विशिष्ट मित्रों या विषयों से संबंधित। इस मामले में, जब भी कोई उपयोगकर्ता छोटी-छोटी क्वेरी करता है, तो हर शार्क को शामिल करने का कोई मतलब नहीं है। उपयोगकर्ता आईडी (या विषय या भौगोलिक क्षेत्र के अनुसार) को शार्प करना समझ में आता है ताकि एक उपयोगकर्ता से संबंधित सभी दस्तावेज़ एक शार्क पर संग्रहीत किए जा सकें, और जब वह उपयोगकर्ता कोई क्वेरी करता है, तो केवल एक शार्क को काम करने की आवश्यकता होती है। यह अन्य शार्क को अन्य उपयोगकर्ताओं के लिए प्रश्नों को संसाधित करने के लिए स्वतंत्र छोड़ देना चाहिए, ताकि कई उपयोगकर्ताओं को एक साथ परोसा जा सके।

4. दस्तावेज़ साझा करना निर्माण समय के अनुसार (जो कि डिफ़ॉल्ट ObjectIds आपको देगा) वांछनीय हो सकता है यदि आपके पास समान समय अवधि के लिए डेटा को देखने वाले बहुत सारे हल्के प्रश्न हैं। उदाहरण के लिए कई अलग-अलग उपयोगकर्ता अलग-अलग ऐतिहासिक चार्ट को क्वेरी कर रहे हैं।

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

आप इस विषय पर आधिकारिक दस्तावेज़ पढ़ना पसंद कर सकते हैं:

• https://docs.mongodb.com/manual/sharding/#shard -कुंजी-रणनीति

• https://docs.mongodb.com/manual/ core/sharding-choose-a-shard-key/