2015-05-19 5 views
6

मेरे पास एक मोंगो सर्वर 16 जीबी मेमोरी के साथ एक वीपीएस पर चल रहा है (हालांकि शायद चुंबकीय डिस्क का उपयोग कर धीमी आईओ के साथ)।

मैं लगभग 35 मिलियन रिकॉर्ड जो मुख्य स्मृति में फ़िट नहीं होता (db.stats() रिपोर्ट 35GB की एक size और 14GB की एक storageSize) का एक संग्रह है, हालांकि 1.7GB totalIndexSize के लिए सूचना दी आराम से वहाँ के अनुरूप होनी चाहिए।

विशेष क्षेत्र bg मैं क्वेरी करने कर रहा हूँ जो मूल्य true या अनुपस्थित पूरी तरह से साथ मौजूद हो सकता है नहीं है (कृपया के बारे में है कि क्या यह सबसे अच्छा डेटा प्रतिनिधित्व है कोई चर्चा - मुझे अभी भी लगता मोंगो अजीब तरह से बर्ताव कर रही है)। इस क्षेत्र को 146 एमबी के एक रिपोर्ट आकार के साथ गैर-स्पैस इंडेक्स के साथ अनुक्रमित किया गया है।

मैं एक डिफ़ॉल्ट कैश आकार के साथ वायर्ड टाइगर स्टोरेज इंजन का उपयोग कर रहा हूं (इसलिए यह लगभग 8 जीबी होना चाहिए)।

मैं bg फ़ील्ड गुम होने वाले रिकॉर्ड की संख्या गिनने की कोशिश कर रहा हूं। (मिनट 5 के आसपास)

> db.entities.find({bg: true}).count() 
8300677 

हालांकि मान अनुपलब्ध के लिए क्वेरी बेहद धीमी गति से है:

> db.entities.find({bg: null}).count() 
27497706 
मेरी आँखों के लिए

, explain()

true मूल्यों की गिनती यों ही तेजी से (कुछ ही सेकंड) है ठीक दिखता है:

> db.entities.find({bg: null}).explain() 
{ 
    "queryPlanner" : { 
     "plannerVersion" : 1, 
     "namespace" : "testdb.entities", 
     "indexFilterSet" : false, 
     "parsedQuery" : { 
      "bg" : { 
       "$eq" : null 
      } 
     }, 
     "winningPlan" : { 
      "stage" : "FETCH", 
      "filter" : { 
       "bg" : { 
        "$eq" : null 
       } 
      }, 
      "inputStage" : { 
       "stage" : "IXSCAN", 
       "keyPattern" : { 
        "bg" : 1 
       }, 
       "indexName" : "bg_1", 
       "isMultiKey" : false, 
       "direction" : "forward", 
       "indexBounds" : { 
        "bg" : [ 
         "[null, null]" 
        ] 
       } 
      } 
     }, 
     "rejectedPlans" : [ ] 
    }, 
    "serverInfo" : { 
     "host" : "mongo01", 
     "port" : 27017, 
     "version" : "3.0.3", 
     "gitVersion" : "b40106b36eecd1b4407eb1ad1af6bc60593c6105" 
    }, 
    "ok" : 1 
} 

हालांकि क्वेरी बनी हुई है बार-बार कॉल के बाद भी जिद्दी धीमी गति से। विभिन्न मूल्यों के लिए अन्य गिनती प्रश्नों तेजी से कर रहे हैं:

> db.entities.find({bg: "foo"}).count() 
0 
> db.entities.find({}).count() 
35798383 

मैं अजीब इस तरह लगता है, के बाद से मैं समझता हूँ कि लापता गैर विरल सूचकांकों में खेतों बस null के रूप में जमा हो जाती है, इसलिए null साथ गिनती क्वेरी समान होना चाहिए एक वास्तविक मूल्य की गणना करने के लिए (या शायद तीन गुना अधिक सकारात्मक मूल्यों के लिए तीन गुना तक, अगर इसे अधिक इंडेक्स प्रविष्टियों या कुछ गिनना है)। वास्तव में, this answernull मानों और .count() से जुड़े समान प्रश्नों पर विशाल गति सुधार की रिपोर्ट करता है। भिन्नता का एकमात्र बिंदु मैं वायर्ड टाइगर के बारे में सोच सकता हूं।

किसी को भी व्याख्या कर सकते हैं क्यों इतनी धीमी गति से या क्या मैं इसे ठीक करने के लिए (अलग कुल से true मायने रखता है के स्पष्ट घटाव, जो ठीक काम करेगा करने से क्या कर सकते हैं शून्य मान गिनती करने के लिए अपनी क्वेरी है, लेकिन संतुष्ट नहीं होता मेरी जिज्ञासा)?

+0

मुझे यह भी मिला है। मुझे बताओ कि फीच मंच में फ़िल्टर है। जब आप किसी चीज के लिए पूछते हैं तो आप पाएंगे। – msaspence

उत्तर

5

यह अपेक्षित व्यवहार है, देखें: https://jira.mongodb.org/browse/SERVER-18653। मुझे एक अजीब कॉल की तरह लग रहा है, लेकिन वहां आप जाते हैं, मुझे यकीन है कि ऐसे प्रोग्रामर हैं जो मोंगोडीबी के बारे में अधिक जानते हैं जो मैं ज़िम्मेदार हूं।

आपको शून्य के अर्थ के लिए एक अलग मूल्य का उपयोग करने की आवश्यकता होगी। मुझे लगता है कि यह इस बात पर निर्भर करेगा कि आप किस क्षेत्र का उपयोग करते हैं। मेरे मामले में यह एक विदेशी संदर्भ है, इसलिए मैं झूठ का मतलब शून्य से शुरू करने जा रहा हूं। यदि आप इसे बुलियन वैल्यू स्टोर करने के लिए उपयोग कर रहे हैं तो आपको "नल", -1, 0 इत्यादि का उपयोग करने की आवश्यकता हो सकती है।

+0

काउंटर के साथ समेकन ढांचे का उपयोग इस समस्या को कम करने के लिए करेगा?उदाहरण के लिए, '{" $ समूह ": {काउंटर: {" $ sum ":" $ _id "}}}' – mils

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