संग्रह को विभाजित करने के लिए MongoDB (noSQL)

जैसा कि पहले ही लिखा जा चुका है, SQL के लिए दूसरा सामान्य रूप जैसा कोई नियम नहीं है।

हालांकि, MongoDB के लिए अनुकूलन से संबंधित कुछ सर्वोत्तम अभ्यास और सामान्य नुकसान हैं जिन्हें मैं यहां सूचीबद्ध करूंगा।

एम्बेडिंग का अत्यधिक उपयोग

बीएसओएन सीमा

आम धारणा के विपरीत, संदर्भों में कुछ भी गलत नहीं है। मान लें कि आपके पास किताबों की एक लाइब्रेरी है, और आप किराये को ट्रैक करना चाहते हैं। आप इस तरह के मॉडल से शुरुआत कर सकते हैं

{
  // We use ISBN for its uniqueness 
  _id: "9783453031456"
  title: "Schismatrix",
  author: "Bruce Sterling",
  rentals: [
    {
      name:"Markus Mahlberg,
      start:"2015-05-05T03:22:00Z",
      due:"2015-05-12T12:00:00Z"
    }
  ]
}

हालांकि इस मॉडल के साथ कई समस्याएं हैं, लेकिन सबसे महत्वपूर्ण स्पष्ट नहीं है - एक किराये की सीमित संख्या होगी। इस तथ्य के कारण कि बीएसओएन दस्तावेजों की आकार सीमा 16 एमबी है।

दस्तावेज़ माइग्रेशन समस्या

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

इसलिए उदाहरण के लिए, हम अपना एकल मॉडल बदलेंगे और दूसरा मॉडल बनाएंगे। सबसे पहले, किताब के लिए मॉडल

{
  _id: "9783453031456",
  title:"Schismatrix",
  author: "Bruce Sterling"
}

किराये के लिए दूसरा मॉडल इस तरह दिखेगा

{
  _id: new ObjectId(),
  book: "9783453031456",
  rentee: "Markus Mahlberg",
  start: ISODate("2015-05-05T03:22:00Z"),
  due: ISODate("2015-05-05T12:00:00Z"),
  returned: ISODate("2015-05-05T11:59:59.999Z")
}

लेखक या किराएदार के लिए पाठ्यक्रम के समान दृष्टिकोण का उपयोग किया जा सकता है।

अति सामान्यीकरण की समस्या

आइए कुछ समय पीछे मुड़कर देखें। एक डेवलपर एक व्यावसायिक मामले में शामिल संस्थाओं की पहचान करेगा, उनकी संपत्तियों और संबंधों को परिभाषित करेगा, उनके अनुसार इकाई वर्गों को लिखेगा, कुछ घंटों के लिए दीवार के खिलाफ अपना सिर पीटेगा ताकि ट्रिपल इनर-आउटर-अप-एंड-बॉन्ड जॉइन काम कर सके। उपयोग के मामले के लिए और सभी हमेशा के लिए खुशी से रहते थे। तो सामान्य रूप से NoSQL और विशेष रूप से MongoDB का उपयोग क्यों करें? क्योंकि उसके बाद कोई भी सुखी नहीं रहा। यह दृष्टिकोण भयानक रूप से मापता है और लगभग अनन्य रूप से स्केल करने का एकमात्र तरीका लंबवत है।

लेकिन नोएसक्यूएल का मुख्य अंतर यह है कि आप अपने डेटा को उन प्रश्नों के अनुसार मॉडल करते हैं जिनका आपको उत्तर पाने की आवश्यकता होती है।

कहा जा रहा है, आइए एक विशिष्ट n:m संबंध देखें और लेखकों से पुस्तकों के संबंध को हमारे उदाहरण के रूप में लें। SQL में, आपके पास 3 टेबल होंगे:दो आपकी संस्थाओं के लिए (किताबें और लेखक ) और एक संबंध के लिए (किस पुस्तक के लेखक कौन हैं? ) बेशक, आप उन तालिकाओं को ले सकते हैं और उनके समकक्ष संग्रह बना सकते हैं। लेकिन, चूंकि मोंगोडीबी में कोई जॉइन नहीं है, इसलिए आपको एक इकाई के संबंधित दस्तावेजों को खोजने के लिए तीन प्रश्नों (पहली इकाई के लिए एक, उसके संबंधों के लिए एक और संबंधित संस्थाओं के लिए एक) की आवश्यकता होगी। इसका कोई मतलब नहीं होगा, क्योंकि n:m संबंधों के लिए तीन तालिका दृष्टिकोण विशेष रूप से सख्त स्कीमा SQL डेटाबेस को लागू करने के लिए आविष्कार किया गया था। चूंकि MongoDB में एक लचीली स्कीमा है, इसलिए पहला प्रश्न यह होगा कि समस्याओं को ध्यान में रखते हुए संबंध को कहाँ संग्रहीत किया जाए। मन में एम्बेडिंग के अति प्रयोग से उत्पन्न। चूंकि एक लेखक आने वाले वर्षों में काफी कुछ किताबें लिख सकता है, लेकिन किसी पुस्तक का लेखकत्व शायद ही कभी बदलता है, तो इसका उत्तर सरल है:हम लेखकों को पुस्तक डेटा में लेखकों के संदर्भ के रूप में संग्रहीत करते हैं

{
  _id: "9783453526723",
  title: "The Difference Engine",
  authors: ["idOfBruceSterling","idOfWilliamGibson"]
}

और अब हम दो प्रश्नों के द्वारा उस पुस्तक के लेखकों को ढूंढ सकते हैं:

var book = db.books.findOne({title:"The Difference Engine"})
var authors = db.authors.find({_id: {$in: book.authors})

मुझे उम्मीद है कि उपरोक्त आपको यह तय करने में मदद करेगा कि वास्तव में आपके संग्रह को कब "विभाजित" करना है और सबसे आम नुकसानों को दूर करना है।

निष्कर्ष

जहां तक ​​आपके सवालों का सवाल है, मेरे जवाब ये हैं

1. जैसा कि पहले लिखा गया था:नहीं , लेकिन तकनीकी सीमाओं को ध्यान में रखते हुए आपको एक विचार देना चाहिए कि यह कब समझ में आ सकता है।
2. यह बुरा नहीं है - जब तक यह आपके उपयोग के मामले में फिट बैठता है . यदि आपके पास एक दी गई श्रेणी और उसका _id है , संबंधित उत्पादों को खोजना आसान है। उत्पाद लोड करते समय, आप आसानी से उन श्रेणियों को प्राप्त कर सकते हैं जो इससे संबंधित हैं, यहां तक ​​कि कुशलता से, जैसे कि _id डिफ़ॉल्ट रूप से अनुक्रमित किया जाता है।
3. मुझे अभी तक एक उपयोग मामला नहीं मिला है जो मोंगोडीबी के साथ नहीं किया जा सकता है, हालांकि कुछ चीजें मोंगोडीबी के साथ थोड़ी अधिक जटिल हो सकती हैं। आपको अपनी कार्यात्मक और गैर-कार्यात्मक आवश्यकताओं का योग लेने के लिए इम्हो क्या करना चाहिए और नुकसान की तुलना में लाभों की जांच करना चाहिए। मेरे अंगूठे का नियम:यदि आपकी आवश्यकताओं की सूची में "मापनीयता" या "उच्च उपलब्धता/स्वचालित विफलता" में से एक है, तो MongoDB एक नज़र से अधिक लायक है।