आपने सही ढंग से देखा है कि दस्तावेजों के अलग-अलग आकार होंगे। तो आप कम से कम 15 bytes सहेज लेंगे प्रति दस्तावेज़ (60% समान दस्तावेजों के लिए) यदि आप दूसरी स्कीमा अपनाने का निर्णय लेते हैं। यह कुछ इस तरह समाप्त होगा 140MB आपके 10 million . के लिए रिकॉर्ड। इससे आपको निम्नलिखित लाभ प्राप्त होंगे:
- HDD बचत। एकमात्र समस्या यह है कि वर्तमान एचडीडी की कीमतों को देखते हुए यह ज्यादातर बेकार है।
- रैम की बचत। हार्ड डिस्क की तुलना में, यह अनुक्रमण के लिए उपयोगी हो सकता है। mongodb में इंडेक्स को रैम में फिट होना चाहिए ताकि अच्छा हासिल किया जा सके। प्रदर्शन
. इसलिए यदि आपके पास इन दो क्षेत्रों पर अनुक्रमणिकाएँ होंगी, तो आप न केवल
140MBसहेजेंगे HDD स्पेस का लेकिन140MB. भी संभावित RAM स्थान का (जो वास्तव में ध्यान देने योग्य है)। - I/O . इनपुट/आउटपुट सिस्टम (डिस्क से पढ़ने/लिखने की गति सीमित है) की सीमा के कारण बहुत सारी अड़चनें आती हैं। आपके दस्तावेज़ों के लिए, इसका अर्थ है कि स्कीमा 2 के साथ आप संभावित रूप से
twice as many documentsप्रति 1 सेकंड। - नेटवर्क . बहुत सी स्थितियों में नेटवर्क आईओ से भी धीमा है, और यदि आप डीबी सर्वर अलग मशीन पर हैं तो आप एप्लिकेशन सर्वर से डेटा को वायर पर भेजना होगा। और आप दुगना डाटा भी भेज पाएंगे।
फायदे के बारे में बताने के बाद, मुझे आपको एक छोटी सी चाबियों के नुकसान के बारे में बताना होगा:
- डेटाबेस की पठनीयता। जब आप
db.coll.findOne()करते हैं और देखता है{_id: 1, t: 13423, a: 3, b:0.2}यह समझना बहुत कठिन है कि वास्तव में यहाँ क्या संग्रहीत है। - आवेदन की पठनीयता डेटाबेस के समान, लेकिन कम से कम यहां आपके पास समाधान हो सकता है। मैपिंग लॉजिक के साथ, जो
currentDate. को रूपांतरित करता है करने के लिएcऔरpriceकरने के लिएpआप एक साफ कोड लिख सकते हैं और एक छोटा स्कीमा बना सकते हैं।
