मेरे पास एक मोंगो सर्वर 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
मायने रखता है के स्पष्ट घटाव, जो ठीक काम करेगा करने से क्या कर सकते हैं शून्य मान गिनती करने के लिए अपनी क्वेरी है, लेकिन संतुष्ट नहीं होता मेरी जिज्ञासा)?
मुझे यह भी मिला है। मुझे बताओ कि फीच मंच में फ़िल्टर है। जब आप किसी चीज के लिए पूछते हैं तो आप पाएंगे। – msaspence