2011-11-18 6 views
5

मैं नोड.जेएस और एक्सप्रेस के साथ एक सामुदायिक साइट बना रहा हूं और लगभग सभी एक्सप्रेस ट्यूटोरियल या उदाहरण मोंगोडीबी का उपयोग करते हैं, इसलिए मैंने इसे चेक आउट किया। अब तक इस्तेमाल किया जाने वाला एकमात्र डीबी MySQL है, लेकिन मैं इससे ज्यादा परिचित नहीं हूं इसलिए यह मुझे मोंगोडीबी में पढ़ने के लिए परेशान नहीं करेगा। मोंगो बहुत अच्छा लग रहा है और दस्तावेज़ मॉडल फायदेमंद हो सकता है। और मोंगोस के साथ इसका उपयोग करना आसान है। लेकिन मैं कुछ सवाल मिला तो मैं बहुत समय खर्च नहीं करते MongoDB उपयोग करने के लिए सीखने अगर यह सब पर फिट नहीं करता है:क्या मोंगो डीबी एक समुदाय साइट के लिए सही डीबी है?

  1. मैं पढ़ा है कि MongoDB अविश्वसनीय है यदि आप केवल एक पर इसका इस्तेमाल मशीन और आप डेटा हानि का सामना कर सकते हैं। क्या वह सही है? प्रोजेक्ट इतना बड़ा नहीं है कि मैं एक और सर्वर बर्दाश्त कर सकता हूं और डेटा हानि पूरी तरह से नहीं है! कल्पना करें कि कुछ फ़ोरम पोस्ट अभी गायब हो गए हैं। लेकिन मुझे लगता है कि अगर ऐसा होता है तो लोग इसका इस्तेमाल नहीं करेंगे।

  2. साइट में एक स्व-निर्माण मंच होगा और मुझे यकीन नहीं है कि एक रिलेशनल डीबी बेहतर होगा या नहीं। हालांकि आप एम्बेडेड पोस्ट के साथ धागे को बचा सकते हैं और इसी तरह। लेकिन मोंगो के रूप में खोज करने का कोई विचार नहीं है, पूर्ण पाठ खोज का समर्थन नहीं करता है। तुम क्या सोचते हो?

  3. मोंगो में एम्बेडेड दस्तावेज़ों का उपयोग कब करें? उदाहरण: उपयोगकर्ता ट्विटर पर स्टेटस अपडेट पोस्ट कर सकता है। क्या आप इन अद्यतनों को उपयोगकर्ता दस्तावेज़ में सहेज लेंगे? बहुत सारे अपडेट हो सकते हैं। या प्रति अद्यतन एक दस्तावेज़ और इसे उपयोगकर्ता आईडी से लिंक करें? 3.1 और एकाधिक दस्तावेज़ों में क्वेरी कैसे करें? आप अपने दोस्तों के अंतिम 10 स्टेटस अपडेट प्राप्त करना चाहते हैं। आप MySQL में जॉइन के साथ ऐसा कर सकते हैं।

  4. क्या MySQL जैसे दस्तावेज़ों के लिए ऑटो-वृद्धिशील आईडी का उपयोग करने का कोई तरीका है? उदाहरण के लिए एक उपयोगकर्ता में एक अद्वितीय पूर्णांक कुंजी होनी चाहिए, लेकिन मुझे नहीं चाहिए कि मोंगो जैसे कुछ यादृच्छिक संख्या इसे उपयोगकर्ता आईडी को छोटा रखें।

  5. आप मोंगोज़ में दौड़ की स्थिति को कैसे संभालेंगे? आप डीबी से एक दस्तावेज़ लोड करते हैं, कुछ संपादित करते हैं और इसे बाद में सहेजते हैं। लेकिन हो सकता है कि यह पहले ही समय में बदल चुका है।

+0

यदि आप mongoDB नहीं जानते हैं, तो इसे क्यों नहीं सीखें? :-) –

+1

अन्य लोगों ने आपके प्रश्न का उत्तर दिया है - मैं सिर्फ मोंगोडीबी को एक कोशिश देने की सिफारिश करना चाहता था क्योंकि यह ताजा हवा का सांस है और साथ काम करने में बहुत सुखद है। – Russell

उत्तर

8

प्रत्येक प्रश्न को हल करने के लिए:

  1. नहीं, यह नहीं सच में अब है। मोंगोडीबी के पुराने संस्करणों में जर्नलिंग नहीं थी, लेकिन वर्तमान संस्करण करते हैं, और v। 2 से, यह डिफ़ॉल्ट रूप से सक्रिय होता है। हालांकि, आपको ड्राइवर स्तर पर SafeMode का उपयोग करना चाहिए जो सुनिश्चित करता है कि ड्राइवर और डेटाबेस के बीच संचार सफल रहे।

  2. एंबेडेड पोस्ट और थ्रेड शायद सबसे अच्छा विकल्प नहीं हो सकता है। हमने एक समान चीज बनाई है, और हम एक फ्लैट संग्रह का उपयोग कर रहे हैं जहां प्रत्येक पोस्ट पेरेंट आईडी और पेरेंट थ्रेड आईडी स्टोर करता है। वहाँ पेशेवरों और एम्बेड करने के विपक्ष रहे हैं, लेकिन हमारे निर्णय के लिए तर्क थे:

    क) कई बार, हम केवल सबसे हाल ही में टिप्पणी साइट-व्यापी या n किसी दिए गए सूत्र में सबसे हाल ही में टिप्पणियां प्राप्त करना चाहते हैं दोनों, जिनमें से एम्बेडेड दस्तावेज़ों का उपयोग करके वास्तव में नहीं किया जा सकता है।

    बी) यदि आपके पास एक ही समय में एक ही विषय के बारे में बहुत से लोग लिख रहे हैं, तो आपको समेकन के बारे में सावधान रहना होगा। इसे हल किया जा सकता है, लेकिन हम अलग-अलग ऑब्जेक्ट्स का उपयोग करके सुरक्षित महसूस करते हैं जो वास्तव में हस्तक्षेप नहीं कर सकते हैं, भले ही आप गलतियां करते हैं

    सी) जैसा कि जो बताता है, आपको एक अलग सिस्टम में पूर्ण-पाठ खोज को संभालना होगा।

  3. यदि आपके पास बहुत सारे अपडेट हैं, तो एम्बेडेड दस्तावेज़ बहुत उपयुक्त नहीं हैं, क्योंकि कंटेनर (संग्रहित आइटम जिसमें एम्बेडेड ऑब्जेक्ट्स हैं) बढ़ेगा। जब यह बढ़ता है, तो मोंगोडीबी को इसे फिर से आवंटित करना होगा, जिसमें अधिक समय और टुकड़े डेटा ले सकते हैं।

    3 (ए)। दोस्तों के स्टेटस अपडेट्स के लिए, फैन-आउट रणनीति का उपयोग करके समझ में आता है। मैं answered a similar question yesterday

  4. ऑटो-वृद्धि संख्याओं का उपयोग न करें। यह डिफ़ॉल्ट रूप से एक दोषपूर्ण डिज़ाइन है, क्योंकि यह वास्तव में वितरित वातावरण में अच्छी तरह से काम नहीं करता है। डीबी के लिए, यह कोई फर्क नहीं पड़ता कि यह int को 0x00000001 या मूल्य 0xfa9ac7335 के साथ स्टोर करता है या नहीं। संख्याओं को छोटा रखने में कोई बात नहीं है। मैं मोंगो ObjectId या Guid/UUID के साथ जाऊंगा। पूर्व में टाइमस्टैम्प बीटीडब्ल्यू भी शामिल है।

  5. मैंने मोंगोस का उपयोग नहीं किया है, लेकिन सामान्य रूप से, निराशावादी और आशावादी ताले की विशिष्ट रणनीतियों हैं।

+0

महान उत्तर के लिए धन्यवाद! मुझे ऑटो-वृद्धि संख्या का उपयोग क्यों नहीं करना चाहिए? यह एक दोषपूर्ण डिजाइन क्यों है? उदाहरण के लिए मुझे यूआरएल में संख्या का उपयोग करने की आवश्यकता होगी। कुछ यादृच्छिक लंबे हेक्स नंबर अच्छा नहीं लग रहा है। – Xomby

+0

अनुक्रमिक आईडी के खिलाफ कई तर्क हैं, यहां मेरे सिर के शीर्ष से कुछ हैं: ए) संदर्भ डालने के लिए, आप ref'd ऑब्जेक्ट की आईडी * पहले * डालने से पहले जानना चाहते हैं ताकि आप वापस लापता न हों डीबी में संदर्भ। बी) ऑटो-इंक्रिमेंटमेंट आईडी का उपयोग आपकी साइट को क्रॉल करने, उपयोगकर्ताओं की संख्या निर्धारित करने के लिए किया जा सकता है, सी) आप 'करीबी' आइटम पा सकते हैं, जो विशिष्ट उपयोगकर्ताओं या ऑब्जेक्ट्स के बारे में जानकारी रिसाव कर सकते हैं डी) क्या आपको कभी भी संग्रह मर्ज करने की आवश्यकता होनी चाहिए , आपको प्राथमिक आईडी को पुन: असाइन करने और सभी संदर्भों को अपडेट करने की आवश्यकता है ई) मास्टर/मास्टर परिदृश्य असंभव हैं (लेकिन मोंगोडीबी मास्टर/मास्टर नहीं है) – mnemosyn

2

यहाँ, NoSQL डेटाबेस की तुलना है उनके stregths, कमजोरियों और परियोजना प्रकार वे के लिए सबसे अच्छा कर रहे हैं दिखा: तो अगर कुछ हो जाता है http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis

4
  1. डिफ़ॉल्ट रूप से MongoDB लिखते हैं, आग और भूल कर रहे हैं गलत डेटा हानि की संभावना है। आप सुरक्षित मोड का उपयोग कर सकते हैं जो आपको प्रतिक्रिया देता है अगर लिखना सफल था या नहीं, तो इसे किसी भी तरह से संभालें। ऐसा कहकर कि मैंने खुद को खोए गए डेटा का अनुभव नहीं किया है। एकाधिक सर्वर प्रतिकृति के लिए उपयोग किया जाएगा जो फेलओवर के लिए प्रयोग किया जाता है, अगर एक नोड दूसरे को चला जाता है तो स्वचालित रूप से मास्टर के रूप में प्रचारित किया जा सकता है।

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

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

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

  5. मैं Mongoose से परिचित नहीं हूँ।

संबंधित मुद्दे