2.6 से पहले इंटरेक्टिव शेल लूप के माध्यम से चलेगा और केवल लूप में अंतिम ऑपरेशन की सफलता (getLastError का उपयोग करके) की जांच करेगा (अधिक विशेष रूप से, इसे getLastError प्रत्येक कैरिज रिटर्न के बाद, आखिरी ऑपरेशन लूप में आखिरी डालने वाला होता है)। 2.6 के साथ, शेल अब लूप के भीतर प्रत्येक व्यक्तिगत ऑपरेशन की स्थिति की जांच करेगा। अनिवार्य रूप से इसका मतलब है कि 2.6 के साथ "धीमा" को वास्तविक प्रदर्शन समस्या के बजाय स्वीकृत बनाम अनजाने लेखन प्रदर्शन के लिए जिम्मेदार ठहराया जा सकता है।
स्वीकृत लेखन डिफ़ॉल्ट रहा है कुछ समय के लिए , और इसलिए मुझे लगता है कि 2.6 में व्यवहार अधिक सही है, हालांकि हममें से उन लोगों के लिए थोड़ा असुविधाजनक है जो मूल व्यवहार के आदी हैं।
प्रदर्शन के अपने पिछले स्तरों पर वापस जाने के लिए उत्तर नए अनॉर्डर्ड बल्क इंसर्ट API . यहाँ एक समयबद्ध संस्करण है:
> db.timecheck.drop();
true
> var bulk = db.timecheck.initializeUnorderedBulkOp(); start = new Date(); for(var i = 0; i < 100000; i++){bulk.insert({"_id" : i})}; bulk.execute({w:1}); end = new Date(); print(end - start);
2246
यह अब अनिवार्य रूप से केवल 2 सेकंड में समान प्रदर्शन पर वापस आ गया है। ज़रूर, यह थोड़ा अधिक भारी है (दंड को क्षमा करें), लेकिन आप वास्तव में जानते हैं कि आपको क्या मिल रहा है, जो मुझे लगता है कि सामान्य रूप से एक अच्छी बात है। यहां एक उल्टा भी है, जब आप समय की जानकारी की तलाश में नहीं हैं। आइए इससे छुटकारा पाएं और फिर से इंसर्ट चलाएं:
> db.timecheck.drop();
true
> var bulk = db.timecheck.initializeUnorderedBulkOp(); for(var i = 0; i < 100000; i++){bulk.insert({"_id" : i})}; bulk.execute({w:1});
BulkWriteResult({
"writeErrors" : [ ],
"writeConcernErrors" : [ ],
"nInserted" : 100000,
"nUpserted" : 0,
"nMatched" : 0,
"nModified" : 0,
"nRemoved" : 0,
"upserted" : [ ]
})
अब हम एक अच्छा परिणाम दस्तावेज़ प्राप्त करते हैं जब हम केवल पिछले ऑपरेशन पर एक चेक के बजाय बल्क इंसर्ट करते हैं (2.4 संस्करण में बाकी सभी अनिवार्य रूप से भेजे और भूल गए थे)। चूंकि यह एक अनियंत्रित बल्क ऑपरेशन है, इसलिए यह जारी रहेगा यदि इसे एक त्रुटि का सामना करना पड़ता है और इस दस्तावेज़ में ऐसी प्रत्येक त्रुटि पर रिपोर्ट करता है। ऊपर के उदाहरण में कुछ भी नहीं देखा जा सकता है, लेकिन कृत्रिम रूप से विफलता परिदृश्य बनाना आसान है। आइए बस पहले से एक मान डालें जो हम जानते हैं कि वह आएगा और इसलिए (डिफ़ॉल्ट) अद्वितीय _id अनुक्रमणिका पर एक डुप्लिकेट कुंजी त्रुटि का कारण बनता है:
> db.timecheck.drop();
true
> db.timecheck.insert({_id : 500})
WriteResult({ "nInserted" : 1 })
> var bulk = db.timecheck.initializeUnorderedBulkOp(); for(var i = 0; i < 100000; i++){bulk.insert({"_id" : i})}; bulk.execute({w:1});
2014-03-28T16:19:40.923+0000 BulkWriteError({
"writeErrors" : [
{
"index" : 500,
"code" : 11000,
"errmsg" : "insertDocument :: caused by :: 11000 E11000 duplicate key error index: test.timecheck.$_id_ dup key: { : 500.0 }",
"op" : {
"_id" : 500
}
}
],
"writeConcernErrors" : [ ],
"nInserted" : 99999,
"nUpserted" : 0,
"nMatched" : 0,
"nModified" : 0,
"nRemoved" : 0,
"upserted" : [ ]
})
अब हम देख सकते हैं कि कितने सफल हुए, कौन से असफल (और क्यों)। इसे स्थापित करना थोड़ा अधिक जटिल हो सकता है, लेकिन कुल मिलाकर मुझे लगता है कि यह एक सुधार है।
उन सभी के साथ, और नए पसंदीदा तरीके की रूपरेखा के साथ, शेल को वापस विरासत मोड में लाने के लिए एक तरीका है। यह समझ में आता है, क्योंकि 2.6 शेल को पुराने सर्वर से कनेक्ट और काम करना पड़ सकता है। यदि आप 2.4 सर्वर से कनेक्ट करते हैं, तो आपके लिए इसका ध्यान रखा जाएगा, लेकिन किसी विशेष कनेक्शन के लिए मामले को बाध्य करने के लिए आप इसे चला सकते हैं:
db.getMongo().forceWriteMode("legacy");
एक बार जब आप कर लें, तो आप 2.6 संस्करण पर वापस लौट सकते हैं:
db1.getMongo().forceWriteMode("commands");
वास्तविक उपयोग के लिए, मेरा crud.js स्निपेट . यह अभी के लिए काम करता है, लेकिन भविष्य में किसी भी समय बिना किसी सूचना के हटाया जा सकता है और वास्तव में व्यापक उपयोग के लिए अभिप्रेत नहीं है, इसलिए अपने जोखिम पर उपयोग करें।
