MongoDB: अनुक्रमण के लिए बहुत सारे क्षेत्र? जेनेरिक इंडेक्स का उपयोग करें

समस्या का सार

ऐसी स्थितियाँ होती हैं जब दस्तावेज़ों के कई अलग-अलग क्षेत्र होते हैं और उन पर प्रभावी प्रश्न रखना आवश्यक होता है। उदाहरण के लिए, एक व्यक्ति का वर्णन करने वाला एक दस्तावेज है:

{ _id: 123, firstName: "John", lastName: "Smith", age: 25, height: 6.0, dob: Date, eyes: "blue", sign: "Capricorn", ... } 

ऐसे दस्तावेजों के अनुसार, आप आंखों के रंग, एक निश्चित ऊंचाई, अंतिम नाम और अन्य विशेषताओं के अनुसार लोगों का चयन कर सकते हैं। लेकिन क्या होगा अगर उदाहरण के लिए एक दस्तावेज़ में दर्जनों फ़ील्ड शामिल हैं, या पहले से ज्ञात नहीं हैं, या प्रत्येक दस्तावेज़ के पास फ़ील्ड का अपना सेट है? इंडेक्स की सहायता से इस समस्या को जल्दी से कैसे हल करें, लेकिन साथ ही साथ उन्हें प्रत्येक क्षेत्र द्वारा नहीं बनाया जाए, क्योंकि यह बहुत महंगा समाधान है।

समाधान # 1: फील्ड नामों और मूल्यों द्वारा यौगिक सूचकांक

हम दस्तावेज़ फ़ील्ड को ऑब्जेक्ट की सूची के रूप में दस्तावेज़ फ़ील्ड को संग्रहीत करने की क्षमता का उपयोग करके डिज़ाइन करेंगे:

 { _id: 123, props: [ { n: "firstName", v: "John"}, { n: "lastName", v: "Smith"}, { n: "age", v: 25}, ... ] } 

समस्या को हल करने के लिए, सूची के अंदर वस्तुओं के नाम और मूल्य से एक समग्र सूचकांक बनाया जाता है। स्पष्टता के लिए, हम prop9 0 से prop0 तक काल्पनिक गुणों से युक्त 5 मिलियन दस्तावेज prop9 जिनका 0 से 1000 तक यादृच्छिक मूल्य है।

 > for (var i = 0; i < 5000000; ++i) { var arr = []; for (var j = 0; j < 10; ++j) { arr.push({n: "prop" + j, v: Math.floor(Math.random() * 1000) }) }; db.generic.insert({props: arr}) } > db.generic.findOne() { "_id": ObjectId("515dd3b4f0bd676b816aa9b0"), "props": [ { "n": "prop0", "v": 40 }, { "n": "prop1", "v": 198 }, ... { "n": "prop9", "v": 652 } ] } > db.generic.ensureIndex({"props.n": 1, "props.v": 1}) > db.generic.stats() { "ns": "test.generic", "count": 5020473, "size": 1847534064, "avgObjSize": 368, "storageSize": 2600636416, "numExtents": 19, "nindexes": 2, "lastExtentSize": 680280064, "paddingFactor": 1, "systemFlags": 1, "userFlags": 0, "totalIndexSize": 1785352240, "indexSizes": { "_id_": 162898624, "props.n_1_props.v_1": 1622453616 }, "ok": 1 } 

इस मामले में, सूचकांक का आकार 1.6 जीबी है, क्योंकि सूचकांक संपत्ति के नाम और उसके मूल्य दोनों को संग्रहीत करता है। अब चलिए उन दस्तावेजों को खोजने की कोशिश करते हैं जिनमें prop1 0 :

 > db.generic.findOne({"props.n": "prop1", "props.v": 0}) { "_id": ObjectId("515dd4298bff7c34610f6ae8"), "props": [ { "n": "prop0", "v": 788 }, { "n": "prop1", "v": 0 }, ... { "n": "prop9", "v": 788 } ] } > db.generic.find({"props.n": "prop1", "props.v": 0}).explain() { "cursor": "BtreeCursor props.n_1_props.v_1", "isMultiKey": true, "n": 49822, "nscannedObjects": 5020473, "nscanned": 5020473, "nscannedObjectsAllPlans": 5020473, "nscannedAllPlans": 5020473, "scanAndOrder": false, "indexOnly": false, "nYields": 0, "nChunkSkips": 0, "millis": 252028, "indexBounds": { "props.n": [ [ "prop1", "prop1" ] ], "props.v": [ [ { "$minElement": 1 }, { "$maxElement": 1 } ] ] }, "server": "agmac.local:27017" } 

इस तरह के समाधान ने अपेक्षित परिणाम नहीं दिया: ~ 50,000 दस्तावेज़ 252 सेकंड में पाए गए। ऐसा इसलिए है क्योंकि प्रत्येक अनुरोध n=prop1 और v=0 दोनों स्थितियों में संलग्न दस्तावेजों के लिए एक साथ मिलने की आवश्यकता नहीं है, इसलिए, जो दस्तावेज़ आवश्यकता n=prop1 और v=0 दोनों को अलग से अंतिम परिणाम में n=prop1 करते हैं, और यह उन सभी के लिए नहीं है उम्मीद। आप $elemMatch का उपयोग करके अनुरोध को परिष्कृत कर सकते हैं:

 > db.generic.findOne({"props": { $elemMatch: {n: "prop1", v: 0} }}) 

अब देखते हैं कि इंडेक्स का उपयोग कैसे किया जाता है और MongoDB v2.2 में क्वेरी कितनी देर तक चलती है:

 > db.generic.find({"props": { $elemMatch: {n: "prop1", v: 0} }}).explain() { "cursor": "BtreeCursor props.n_1_props.v_1", "isMultiKey": true, "n": 5024, "nscannedObjects": 5020473, "nscanned": 5020473, "nscannedObjectsAllPlans": 5020473, "nscannedAllPlans": 5020473, "scanAndOrder": false, "indexOnly": false, "nYields": 0, "nChunkSkips": 0, "millis": 278784, "indexBounds": { "props.n": [ [ "prop1", "prop1" ] ], "props.v": [ [ { "$minElement": 1 }, { "$maxElement": 1 } ] ] }, "server": "agmac.local:27017" } 

अनुरोध को सही तरीके से निष्पादित किया गया था और 5024 दस्तावेजों को वापस कर दिया गया था, लेकिन फिर भी धीरे-धीरे! explain कमांड से, आप देख सकते हैं कि इसका कारण यह है कि रेंज अभी भी फ़ील्ड v लिए उपयोग किया जाता है। ऐसा क्यों होता है यह समझने के लिए, हम एक उदाहरण का अधिक विस्तार से विश्लेषण करेंगे। यदि आप $elemMatch उपयोग नहीं करते हैं $elemMatch तो व्यक्तिगत रूप से कम से कम एक क्वेरी शर्तों को संतुष्ट करने वाले फ़ील्ड के सभी संयोजन अंतिम चयन में आ सकते हैं। इस मामले में, सूचकांक को बनाए रखने के लिए इसका उपयोग करना असंभव होगा, क्योंकि इससे बड़ी संख्या में संभावित संयोजन हो सकते हैं। इसलिए, जब संकेत दिया जाता है, तो MongoDB ने संलग्न दस्तावेजों के मूल्यों से बी-ट्री बनाने और संभावित संयोजनों ( $elemMatch लिए मुख्य व्यवहार) को $elemMatch । लेकिन $elemMatch साथ अनुरोध इतना धीमा क्यों चल रहा है? यह एक बग के कारण था जो कि MongoDB v2.4 में SERVER-3104 द्वारा तय किया गया था। निश्चित संस्करण में एक ही अनुरोध की जाँच करें:

 > db.generic.find({"props": { $elemMatch: {n: "prop1", v: 0} }}).explain() { "cursor": "BtreeCursor props.n_1_props.v_1", "isMultiKey": true, "n": 5024, "nscannedObjects": 5024, "nscanned": 5024, "nscannedObjectsAllPlans": 5024, "nscannedAllPlans": 5024, "scanAndOrder": false, "indexOnly": false, "nYields": 0, "nChunkSkips": 0, "millis": 21, "indexBounds": { "props.n": [ [ "prop1", "prop1" ] ], "props.v": [ [ 0, 0 ] ] }, "server": "agmac.local:27017" } 

अनुरोध 21 मिलीसेकंड में पूरा हो गया था!

समाधान # 2: एक सामान्य सूचकांक

समस्या को हल करने का एक अन्य तरीका property: value रूप में सूची में फ़ील्ड को संग्रहीत करना है property: value ऑब्जेक्ट। यह समाधान MongoDB v2.2 और v2.4 में काम करता है। फॉर्म के दस्तावेज बनाएं:

 > for (var i = 0; i < 5000000; ++i) { var arr = []; for (var j = 0; j < 10; ++j) { var doc = {}; doc["prop" + j] = Math.floor(Math.random() * 1000); arr.push(doc) }) }; db.generic2.insert({props: arr}) } > db.generic2.findOne() { "_id": ObjectId("515e5e6a71b0722678929760"), "props": [ { "prop0": 881 }, { "prop1": 47 }, ... { "prop9": 717 } ] } 

सूचकांक बनाएँ:

 > db.generic2.ensureIndex({props: 1}) > db.generic2.stats() { "ns": "test.generic2", "count": 5000000, "size": 1360000032, "avgObjSize": 272.0000064, "storageSize": 1499676672, "numExtents": 19, "nindexes": 2, "lastExtentSize": 393670656, "paddingFactor": 1, "systemFlags": 1, "userFlags": 0, "totalIndexSize": 2384023488, "indexSizes": { "_id_": 162269072, "props_1": 2221754416 }, "ok": 1 } 

सूचकांक का आकार ~ 2.2 जीबी था, जो समाधान # 1 की तुलना में 40% अधिक है क्योंकि संलग्न दस्तावेजों के बीएसओएन सूचकांक में खुद को बीएलओबी के रूप में संग्रहीत करता है। अब क्वेरी चलाएँ:

 > db.generic2.find({"props": {"prop1": 0} }).explain() { "cursor": "BtreeCursor props_1", "isMultiKey": true, "n": 4958, "nscannedObjects": 4958, "nscanned": 4958, "nscannedObjectsAllPlans": 4958, "nscannedAllPlans": 4958, "scanAndOrder": false, "indexOnly": false, "nYields": 0, "nChunkSkips": 0, "millis": 15, "indexBounds": { "props": [ [ { "prop1": 0 }, { "prop1": 0 } ] ] }, "server": "agmac.local:27017" } 

अनुरोध 15 एमएस में पूरा हुआ, जो पहले समाधान से तेज है! लेकिन एक शर्त है, एक अनुरोध को संकलित करते समय, पूरे उप-दस्तावेज़ ऑब्जेक्ट का वर्णन करना आवश्यक है। उन दस्तावेजों का चयन करने के लिए जो अनुरोध को संतुष्ट करते हैं जहां prop1 0 से 9 तक हो सकता है, आपको अनुरोध पूरा करना होगा:

 > db.generic2.find({"props": { $gte: {"prop1": 0}, $lte: {"prop1": 9} }) 

यह थोड़ा असुविधाजनक है, और यह भी कि यदि संलग्न दस्तावेज में अन्य क्षेत्र हैं, तो उन्हें अनुरोध की तैयारी में भाग लेना चाहिए (क्योंकि संलग्न दस्तावेज बीएलओबी के रूप में संग्रहीत हैं)।
एक और सीमा भी है: केवल फ़ील्ड मानों को अलग-अलग करना असंभव है, जबकि समाधान # 1 में आप 10 मान के साथ सभी दस्तावेज़ों के उदाहरण के लिए खोज करने के लिए props.v सूचकांक का निर्माण कर सकते हैं। समाधान # 2 इसकी अनुमति नहीं देता है।

निष्कर्ष

आप देख सकते हैं कि MongoDB v2.4 अब बड़ी संख्या में फ़ील्ड्स के साथ दस्तावेज़ों के लिए सामान्य अनुक्रमित बनाने के लिए एक सरल और प्रभावी समाधान प्रदान करता है, जिसका उपयोग आप अपनी "बिग डेटा" परियोजनाओं के लिए कर सकते हैं।