MongoDB
 sql >> डेटाबेस >  >> NoSQL >> MongoDB

MongoDb:कई खोज योग्य फ़ील्ड वाले डेटा के लिए सही (समग्र) अनुक्रमणिका कैसे बनाएं

मैं उदाहरण के द्वारा यह समझाने की कोशिश करूंगा कि इसका क्या अर्थ है। बी-पेड़ पर आधारित इंडेक्स कुछ मोंगोडब विशिष्ट नहीं है। इसके विपरीत यह सामान्य अवधारणा है।

इसलिए जब आप एक इंडेक्स बनाते हैं - तो आप डेटाबेस को कुछ खोजने का एक आसान तरीका दिखाते हैं। लेकिन यह इंडेक्स मूल दस्तावेज़ के स्थान की ओर इशारा करते हुए एक पॉइंटर के साथ कहीं संग्रहीत होता है। इस जानकारी का आदेश दिया गया है और आप इसे बाइनरी ट्री के रूप में देख सकते हैं जिसमें वास्तव में अच्छी संपत्ति है:खोज को O(n) से घटाया गया है (रैखिक स्कैन) से O(log(n)) . जो बहुत तेज है क्योंकि हर बार जब हम अपनी जगह को आधा कर देते हैं (संभावित रूप से हम समय को 10^6 से घटाकर 20 लुकअप कर सकते हैं)। उदाहरण के लिए हमारे पास {a : some int, b: 'some other things'} फ़ील्ड के साथ एक बड़ा संग्रह है और यदि हम इसे a से अनुक्रमित करते हैं, तो हम एक अन्य डेटा संरचना के साथ समाप्त होते हैं जिसे a . द्वारा क्रमबद्ध किया जाता है . यह इस तरह दिखता है (इससे मेरा मतलब यह नहीं है कि यह एक और संग्रह है, यह सिर्फ प्रदर्शन के लिए है):

{a : 1, pointer: to the field with a = 1}, // if a is the smallest number in the starting collection
...
{a : 999, pointer: to the field with a = 990} // assuming that 999 is the biggest field

तो अभी हम एक क्षेत्र a =18 की तलाश कर रहे हैं। सभी तत्वों के माध्यम से एक-एक करके जाने के बजाय हम बीच में कुछ लेते हैं और यदि यह बड़ा है तो 18, तो हम निचले हिस्से को आधा में विभाजित कर रहे हैं और वहां तत्व की जांच कर रहे हैं . हम तब तक जारी रखते हैं जब तक हमें a =18 नहीं मिल जाता। फिर हम पॉइंटर को देखते हैं और इसे जानकर हम मूल फ़ील्ड निकालते हैं।

यौगिक सूचकांक के साथ स्थिति समान है (एक तत्व द्वारा आदेश देने के बजाय हम कई द्वारा आदेश देते हैं)। उदाहरण के लिए आपके पास एक संग्रह है:

{ "item": 5, "location": 1, "stock": 3, 'a lot of other fields' }  // was stored at position 5 on the disk
{ "item": 1, "location": 3, "stock": 1, 'a lot of other fields' }  // position 1 on the disk
{ "item": 2, "location": 5, "stock": 7, 'a lot of other fields' }  // position 3 on the disk
... huge amount of other data
{ "item": 1, "location": 1, "stock": 1, 'a lot of other fields' }  // position 9 on the disk
{ "item": 1, "location": 1, "stock": 2, 'a lot of other fields' }  // position 7 on the disk

और एक इंडेक्स {"आइटम":1, "स्थान":1, "स्टॉक":1} चाहते हैं। लुकअप टेबल इस तरह दिखेगी (एक बार और - यह दूसरा संग्रह नहीं है, यह सिर्फ प्रदर्शन के लिए है):

{ "item": 1, "location": 1, "stock": 1, pointer = 9 }
{ "item": 1, "location": 1, "stock": 2, pointer = 7 }
{ "item": 1, "location": 3, "stock": 1, pointer = 1 }
{ "item": 2, "location": 5, "stock": 7, pointer = 3 }
.. huge amount of other data (but not necessarily here. If item would be one it would be somewhere next to items 1)
{ "item": 5, "location": 1, "stock": 3, pointer = 5 }

देखें कि यहां सब कुछ मूल रूप से आइटम द्वारा, फिर स्थान के अनुसार और फिर पॉइंटर द्वारा क्रमबद्ध किया गया है। उसी तरह जैसे एकल इंडेक्स के साथ हमें सब कुछ स्कैन करने की आवश्यकता नहीं है। अगर हमारे पास कोई क्वेरी है जो item = 2, location = 5 and stock = 7 . की तलाश में है हम जल्दी से पहचान सकते हैं कि item = 2 . के साथ दस्तावेज़ कहाँ हैं हैं और फिर उसी तरह जल्दी से पहचानते हैं कि location 5 . के साथ इन आइटम्स में से कहां आइटम है और इसी तरह।

और अभी एक दिलचस्प हिस्सा . इसके अलावा हमने केवल एक इंडेक्स बनाया है (हालांकि यह एक कंपाउंड इंडेक्स है, यह अभी भी एक इंडेक्स है) हम इसका उपयोग तत्व को जल्दी से खोजने के लिए कर सकते हैं

  • केवल item . द्वारा . वास्तव में हमें केवल पहला कदम उठाने की जरूरत है। तो एक और इंडेक्स {स्थान:1} बनाने का कोई मतलब नहीं है क्योंकि यह पहले से ही कंपाउंड इंडेक्स द्वारा कवर किया गया है।
  • भी हम जल्दी से केवल item and by location ढूंढ सकते हैं (हमें केवल 2 चरणों की आवश्यकता है)।

कूल 1 इंडेक्स लेकिन तीन अलग-अलग तरीकों से हमारी मदद करता है। लेकिन एक मिनट रुकिए:क्या होगा अगर हम item and stock के द्वारा खोजना चाहते हैं . ओह, ऐसा लगता है कि हम इस क्वेरी को भी तेज़ कर सकते हैं। हम लॉग (एन) में विशिष्ट आइटम वाले सभी तत्वों को ढूंढ सकते हैं और ... यहां हमें रुकना होगा - जादू समाप्त हो गया है। हमें उन सभी के माध्यम से पुनरावृति करने की आवश्यकता है। लेकिन फिर भी बहुत अच्छा है।

लेकिन क्या यह हमें अन्य प्रश्नों में मदद कर सकता है। आइए location के आधार पर एक क्वेरी देखें जो लगता है कि पहले से ही ऑर्डर किया गया था। लेकिन अगर आप इसे देखेंगे - आप देखेंगे कि यह एक गड़बड़ है। एक शुरुआत में और फिर एक अंत में। यह आपकी बिल्कुल भी मदद नहीं कर सकता।

मुझे आशा है कि यह कुछ बातें स्पष्ट करता है:

  • सूचकांक अच्छे क्यों हैं (O(n) से संभावित O(log(n)) तक समय कम करें
  • क्यों कंपाउंड इंडेक्स कुछ प्रश्नों में मदद कर सकते हैं, फिर भी हमने उस विशेष क्षेत्र पर एक इंडेक्स नहीं बनाया है और कुछ अन्य प्रश्नों में मदद नहीं की है।
  • यौगिक अनुक्रमणिका द्वारा कौन से अनुक्रमित किए जाते हैं
  • सूचकांक क्यों नुकसान पहुंचा सकते हैं (यह अतिरिक्त डेटा संरचना बनाता है जिसे बनाए रखा जाना चाहिए)

और यह एक और मान्य बात बताना चाहिए:अनुक्रमणिका चांदी की गोली नहीं है . आप अपने सभी प्रश्नों को तेज़ नहीं कर सकते हैं, इसलिए यह सोचना मूर्खतापूर्ण लगता है कि सभी क्षेत्रों में अनुक्रमणिका बनाने से सब कुछ बहुत तेज़ हो जाएगा।



  1. Redis
  2.   
  3. MongoDB
  4.   
  5. Memcached
  6.   
  7. HBase
  8.   
  9. CouchDB
  1. मोंगोडब और सी # में काम की इकाई

  2. क्या MongoDB पर एकत्रीकरण पाइपलाइन के अंदर कास्ट डेटा टाइप करना संभव है?

  3. MongoDB:उप-दस्तावेज़ आईडी द्वारा कैसे खोजें?

  4. मोंगोडब संग्रह और एक पायथन डिक्ट मर्ज करें

  5. mongoDB में समूह कैसे करें और परिणाम में सभी फ़ील्ड वापस करें