क्या मुझे मोंगोडीबी में ऑटो-इंक्रिमेंटिंग लागू करनी चाहिए?

मैं चयनित उत्तर के लेखक से दृढ़ता से असहमत हूं कि MongoDB में कोई ऑटो-इंक्रीमेंट आईडी नहीं है और इसके अच्छे कारण हैं . हम उन कारणों के बारे में नहीं जानते हैं जिनकी वजह से 10gen ने ऑटो-इंक्रीमेंटेड आईडी के उपयोग को प्रोत्साहित नहीं किया। यह अटकलें हैं। मुझे लगता है कि 10gen ने यह विकल्प इसलिए बनाया क्योंकि क्लस्टर वातावरण में 12-बाइट आईडी की विशिष्टता सुनिश्चित करना आसान है। यह डिफ़ॉल्ट समाधान है जो अधिकांश नवागंतुकों के लिए उपयुक्त है इसलिए उत्पाद अपनाने को बढ़ाता है जो 10gen के व्यवसाय के लिए अच्छा है।

अब मैं सभी को व्यावसायिक वातावरण में ObjectIds के साथ अपने अनुभव के बारे में बताता हूँ।

मैं सोशल नेटवर्क बना रहा हूं। हमारे पास लगभग 6 मिलियन उपयोगकर्ता हैं और प्रत्येक उपयोगकर्ता के लगभग 20 मित्र हैं।

अब कल्पना करें कि हमारे पास एक संग्रह है जो उपयोगकर्ताओं के बीच संबंधों को संग्रहीत करता है (जो अनुसरण करता है)। यह ऐसा दिखता है

_id : ObjectId
user_id : ObjectId
followee_id : ObjectId

जिस पर हमारे पास अद्वितीय समग्र अनुक्रमणिका है {user_id, followee_id} . हम इस सूचकांक का आकार 12*2*6M*20 =2GB होने का अनुमान लगा सकते हैं। अब मेरे द्वारा अनुसरण किए जाने वाले लोगों के तेजी से देखने के लिए यह सूचकांक है। मुझे फॉलो करने वाले लोगों को तेजी से देखने के लिए मुझे रिवर्स इंडेक्स चाहिए। यह एक और 2GB है।

और यह सिर्फ शुरुआत है। मुझे इन आईडी को हर जगह ले जाना है। हमारे पास गतिविधि क्लस्टर है जहां हम आपकी समाचार फ़ीड संग्रहीत करते हैं। वह हर घटना जो आप या आपके मित्र करते हैं। कल्पना कीजिए कि इसमें कितनी जगह लगती है।

और अंत में हमारे इंजीनियरों में से एक ने अनजाने में निर्णय लिया और संदर्भ को स्ट्रिंग के रूप में संग्रहीत करने का निर्णय लिया जो ObjectId का प्रतिनिधित्व करता है जो इसके आकार को दोगुना करता है।

क्या होता है अगर कोई इंडेक्स रैम में फिट नहीं होता है? कुछ भी अच्छा नहीं, 10gen कहते हैं:

जब कोई अनुक्रमणिका RAM में फ़िट होने के लिए बहुत बड़ी होती है, तो MongoDB को डिस्क से अनुक्रमणिका को पढ़ना चाहिए, जो RAM से पढ़ने की तुलना में बहुत धीमा ऑपरेशन है। ध्यान रखें कि कोई अनुक्रमणिका RAM में तब फ़िट हो जाती है जब आपके सर्वर में शेष कार्यशील सेट के साथ संयुक्त अनुक्रमणिका के लिए RAM उपलब्ध हो।

इसका मतलब है कि पढ़ना धीमा है। ताला विवाद बढ़ जाता है। लेखन भी धीमा हो जाता है। 80%-निश में लॉक विवाद को देखना अब मेरे लिए सदमा नहीं है।

इससे पहले कि आप इसे जानते, आपने 460GB क्लस्टर के साथ समाप्त कर दिया, जिसे आपको शार्प में विभाजित करना होगा और जिसे हेरफेर करना काफी कठिन है।

फेसबुक यूजर आईडी के रूप में 64-बिट लंबा उपयोग करता है :) इसका एक कारण है। आप अनुक्रमिक आईडी उत्पन्न कर सकते हैं

• 10gen की सलाह ।
• काउंटरों के भंडारण के रूप में mysql का उपयोग करना (यदि आप गति के बारे में चिंतित हैं तो हैंडलरसॉकेट )
• आपके द्वारा बनाई गई आईडी जनरेटिंग सेवा का उपयोग करना या Snowflake ट्विटर द्वारा।

तो यहां सभी के लिए मेरी सामान्य सलाह है। कृपया अपना डेटा यथासंभव छोटा करें। जब आप बड़े हो जाएंगे तो यह आपको कई रातों की नींद हराम कर देगा।