कार्रवाई में MongoDb - ऑनलाइन स्टोर

जल्द ही मैं MongoDb से मिला एक साल हो जाएगा। मैं उसके साथ काम करना शुरू करने वाला पहला नहीं था, लेकिन, फिर भी, इस तकनीक को अभी भी प्रायोगिक माना जाता है।

सामान्य तौर पर, मैं यह कहूंगा: MS SQL के साथ MongoDB के साथ काम करना अधिक सुविधाजनक है। एसक्यूएल की तुलना में नियमित रूप से स्क्रिप्ट की आवश्यकता होती है, हालांकि, परिणामस्वरूप, आप अधिक जानते हैं कि आपके डेटाबेस की व्यवस्था कैसे की जाती है और बेहतर नियंत्रण क्या धीमा होगा और क्या नहीं होगा।

हबल "हैलो वर्ल्ड" की शैली में अनुप्रयोगों से भरा है, इसलिए हम पर्यावरण के आरंभ को छोड़ देंगे और सीधे और अधिक उन्नत मुद्दों पर जाएंगे, अर्थात्:

• संपूर्ण ऑब्जेक्ट को संग्रहीत करना अधिक सुविधाजनक क्यों है, और तालिकाओं के अनुसार नहीं?
• संबंधों से कैसे निपटें?

संपूर्ण ऑब्जेक्ट को संग्रहीत करना अधिक सुविधाजनक क्यों है, और तालिकाओं के अनुसार नहीं?

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

ऐसी किसी भी लिपि का C # में वर्णन करना सीधा है; लेकिन एक प्रभावी डेटा लेयर बनाना जो सैकड़ों हजारों रिकॉर्ड पर काम करता है, मुश्किल होगा।

उसी समय, MongoDB का उपयोग करके, आप एक सिंगल कॉल के साथ इस तरह के ऑब्जेक्ट को बचा सकते हैं:

DocumentCollection.Save<T>(document); 

सभी नेस्टेड वर्गों के साथ इसे डाउनलोड करना भी प्राथमिक है:

 DocumentCollection.FindOneById(id); 

उदाहरण के लिए, किसी उत्पाद की प्रस्तुति को देखें । डेटाबेस के लिए एक एकल कॉल के लिए - श्रेणी आईडी और SeoFreindlyUrl, जो 0.0012s (!) लेता है, द्वारा खोजें।
- उचित उत्पाद गुण
- इसके पैरामीटर (इस मामले में, केवल दो, लेकिन सामान्य तौर पर उनकी संख्या और प्रकार मनमानी हैं)
- चित्र (श्रेणियों में पुन: उपयोग; 2 टुकड़े, प्रत्येक में url + आकार हैं)
- वीडियो (अगर वहाँ थे)
- संबंधित उत्पाद (लिंक)
- बिक्री की शर्तें (यह ऑब्जेक्ट वारंटी अवधि के विरासत में प्राप्त कॉन्फ़िगरेशन के लिए श्रेणियों और सिस्टम सेटिंग्स में पुन: उपयोग किया जाता है, वापसी की संभावना)
- निर्माता
- एसईओ लाइनों (ब्राउज़र शीर्षक, मेटा टैग, एसईओ पाठ)

और मैं तुरंत प्रतिपादन के लिए आगे बढ़ सकता हूं।

आंकड़ों के लिए: वर्तमान में उत्पाद तालिका में 154 हजार प्रविष्टियां हैं; औसतन, एक रिकॉर्ड में 22KB लगता है; और टेबल का आकार 4GB है।

ऐसी जटिल वस्तु को पढ़ने का सबसे अच्छा तरीका, अगर हम SQL सर्वर का उपयोग कर रहे थे, तो xml में सभी गुणों को मैन्युअल रूप से अनुक्रमित करना होगा। MongoDB यह सब बिना किसी प्रयास के प्रदान करता है।

हमारी पूरी प्रणाली तीन वर्गों पर आधारित है:
- बेसमोंगोक्लास (आईडी, शीर्षक, अंतिम परिवर्तन)
- EntityRef (लिंक, आईडी और शीर्षक शामिल हैं, और अधिक परिष्कृत वारिस हैं)
- बेसरेपोसिटरी, जो काम के लिए सभी आवश्यक तरीकों को लागू करता है। हमने GetById, Get (क्वेरी), FirstOrDefault, GetAll, GetByIds (आईडी सूची द्वारा), GetByEntityRefs (EntityRef सूची द्वारा), सहेजें, DeleteById, DeleteByQuery को चुना।

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

MongoDB सबसे सुविधाजनक आधार है जब आपको पदानुक्रमित जानकारी को बचाने की आवश्यकता होती है। दुनिया ऐसी है कि फ्लैट डेटा बहुत छोटा है।

पुनश्च: बुनियादी कक्षाओं और भंडार की सूची यहां से डाउनलोड की जा सकती है ।

संबंधों से कैसे निपटें?

बेशक, मोंगो में कोई संबंध नहीं हैं। Abo.ua प्रोजेक्ट में , हम निम्नलिखित दृष्टिकोण का उपयोग करते हैं:

एक उत्पाद में एक श्रेणी हो सकती है (हमारे पास अधिक है, लेकिन मैं इसे थोड़ा सरल करता हूं)। स्वयं उत्पाद के प्रकार में, निम्नलिखित शाब्दिक रूप से लिखा गया है:

 public EntityRef Category { get; set; } [BsonIgnore] // ,      public Category CategoryValue { get { if (Category == null || Category .IsEmpty()) return null; return AppRequestContext.Factory.BuildCategoryRepository().GetById(Category.Id); } } 

जब हम श्रेणी बदलते हैं, तो हम श्रेणी निर्धारित करते हैं। जब हमें किसी श्रेणी के बारे में कुछ और जानने के लिए सुविधाजनक तरीके की आवश्यकता होती है, तो हम श्रेणीवैल्यू की ओर मुड़ते हैं।

प्रूफ़रीडिंग और डिसरराइज़िंग श्रेणियों पर समय बर्बाद न करने के लिए, जिनमें से, संख्या, निश्चित रूप से, शायद ही कभी बदलती है, श्रेणीप्रतिपादिक उन सभी को RAM में, ObjectId -> श्रेणी शब्दकोश में बदलता है, जिसकी गति MongoDB पर कॉल से अधिक है।
जब कम से कम कुछ श्रेणी बदलती है, तो हम पूरे शब्दकोश का पुनर्निर्माण करते हैं।

आप निश्चित रूप से मेमोरी डेटाबेस का उपयोग कर सकते हैं, लेकिन प्रयोगों से पता चला है कि यह मौलिक रूप से प्रक्रिया की स्मृति से धीमी है।

एक और संबंधपरक मुद्दा संबंधित वस्तुओं में जानकारी को अद्यतन कर रहा है। उदाहरण के लिए, श्रेणी बदल दी गई / हटा दी गई, लेकिन हम चाहते हैं कि उत्पाद में प्रासंगिक जानकारी हो:
1. हमेशा गैर-समग्र जानकारी के लिए तैयार रहें। ऊपर दिए गए कोड से, यदि कोई ऐसी श्रेणी नहीं है तो श्रेणीवैल्यू वापस आ जाएगी; और वेबसाइट 404 कोड वापस कर देगी। यह एक और सरल परिदृश्य है। जब हम वस्तुओं को घटाते हैं, तो हम गुणों की तुलना माल के प्रकारों की परिभाषाओं से करते हैं: क्या कुछ संपत्ति नष्ट कर दी गई है? क्या आपने इसमें अनुमत मूल्यों की सूची को बदल दिया है? एक प्रकार में जोड़े गए गुणों के लिए डिफ़ॉल्ट मान क्या है? यह जटिल लगता है, लेकिन वास्तव में, जब सभी डेटा हाथ में होते हैं, तो हम 0.1 एस के भीतर 1000 उत्पादों को देखने का प्रबंधन करते हैं, जो काफी पर्याप्त है।
2. जब आपने कोड को डेटा की अखंडता को "ठीक" करने के लिए सिखाया है, तो डेटाबेस में डेटा को सही करने वाले कोड को लिखना आसान हो जाता है। यह कुछ इस तरह दिखता है:

 var products = prodRepo.GetAll().OrderBy(p => p.Id).Skip(start).Take(portionSize).ToArray(); prodRepo.JoinPropertyTypes(products); //       products.AsParallel().ForAll(p => prodRepo.Save(p)); 

जो कुछ बचता है वह सभी वस्तुओं के लिए ऐसे कोड (अतुल्यकालिक) को प्रभावित करने के लिए है।

निम्नलिखित भागों में

मैं वर्णन करूंगा:

• क्या समूह के बिना जीवन है?
• मोंगोडब में प्रासंगिकता के साथ पूर्ण-पाठ खोज कैसे व्यवस्थित करें?
• वास्तविक पर्यावरण विन्यास