पहली बात जो यहाँ दिमाग में आती है वह यह है:एक संदर्भ को संग्रहीत करने की लागत आपको एक उप-दस्तावेज़ में संग्रहीत करने की लागत से 5000 गुना अधिक क्यों है?
ठीक है, आपके स्कीमा को देखकर मेरा मानना है कि सबसे अच्छा तरीका शब्दों के लिए अलग संग्रह है, पैकेज नहीं।
पहला लाल झंडा जो मैंने देखा वह है आपका दोहरा घोंसला यहाँ:
packages : [{
package : {type: Schema.Types.ObjectId, ref: 'Packages'},
from : {type : Schema.Types.ObjectId, ref :'Languages'},
to : {type : Schema.Types.ObjectId, ref :'Languages'},
words : [{
word: {type: String},
progress: {type: Number,default : 0}
}]
}]
words MongoDB के वर्तमान संस्करण में उप-दस्तावेज़ के साथ काम करना बहुत कठिन होगा, आमतौर पर 2-3 स्तरों में गहरी समस्याएँ होने लगती हैं, विशेष रूप से स्थितीय ऑपरेटरों के साथ।
अब इस बात पर विचार करते हुए कि आपको हमेशा उच्चतम संभव मूल्य से काम करना चाहिए जो आपको यहां मिल सकता है:
आप इस दस्तावेज़ के आवास की लागत पर भी विचार करने गए हैं। आपको जिन ऑपरेटरों की आवश्यकता होगी, वे स्मृति में होंगे जैसे कि $pull , $push , $addToSet आदि जिसका अर्थ है कि आपके पूरे दस्तावेज़ को क्रमबद्ध करने और MongoDB के मूल C++ structs में लोड करने की आवश्यकता होगी। उन दस्तावेज़ों के ट्रैफ़िक के आधार पर यह एक अत्यंत खपत वाला कार्य होगा।
आपकी टिप्पणी को ध्यान में रखते हुए:
यह मुख्य उपयोगकर्ता दस्तावेज़ के भीतर शब्दों को एम्बेड करने के ताबूत में केवल एक और कील डालता है। पिछले पैराग्राफ में मैंने जो कहा था, उसे ध्यान में रखते हुए यह words पर इन-मेमोरी ऑपरेटरों का उपयोग करने की लागत के साथ अच्छी तरह से काम नहीं करेगा सरणी।
यह बहुत बेहतर काम करेगा यदि शब्दों को विभाजित कर दिया जाए, $slice एक मेमोरी में रहने वाला ऑपरेटर भी है और संभवत:यहां कम प्रदर्शन का सामना करना पड़ेगा।
और यह एक त्वरित तर्कपूर्ण प्रतिक्रिया है। मुझे यकीन है कि और भी बहुत कुछ है जो मैं अपने कारण के बारे में बता सकता हूं लेकिन वह पर्याप्त होना चाहिए।
