Før 2.6 ville den interaktive shell løbe gennem løkken og kun kontrollere succesen (ved hjælp af getLastError) af den sidste operation i løkken (mere specifikt kaldte den getLastError efter hver vognretur, hvor den sidste operation er den sidste indsats i løkken). Med 2.6 vil skallen nu kontrollere status for hver enkelt operation i løkken. Det betyder i bund og grund, at "langsomheden" med 2.6 kan tilskrives anerkendt versus ikke-anerkendt skriveydeevne snarere end et faktisk ydelsesproblem i sig selv.
Anerkendte skrivninger har været standard i nogen tid nu , og derfor tror jeg, at adfærden i 2.6 er mere korrekt, men lidt ubelejlig for dem af os, der er vant til den oprindelige adfærd.
For at komme tilbage til dine tidligere præstationsniveauer er svaret at bruge den nye uordnet bulk insert API . Her er en tidsindstillet version:
> 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
Det er nu tilbage til stort set den samme ydeevne på lidt over 2 sekunder. Nok, det er lidt mere omfangsrigt (undskyld ordspillet), men du ved præcis, hvad du får, hvilket jeg synes er en god ting generelt. Der er også en fordel her, når du ikke leder efter timing information. Lad os slippe af med det og køre indsatsen igen:
> 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" : [ ]
})
Nu får vi et flot resultatdokument, når vi laver bulk-indsættelsen, snarere end en kontrol af blot de sidste operationer (alle resten i 2.4-versionen var i det væsentlige send og glemme). Fordi det er en uordnet masseoperation, vil den fortsætte, hvis den støder på en fejl og rapportere om hver sådan fejl i dette dokument. Der er ingen at se i eksemplet ovenfor, men det er let kunstigt at skabe et fiasko. Lad os bare forudindsætte en værdi, som vi ved vil komme op og dermed forårsage en duplikatnøglefejl på det (standard) unikke _id-indeks:
> 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" : [ ]
})
Nu kan vi se, hvor mange der fik succes, hvilken en der mislykkedes (og hvorfor). Det kan være lidt mere kompliceret at sætte op, men generelt synes jeg, det er en forbedring.
Med alt det sagt, og den nye foretrukne måde skitseret, er der en måde at tvinge skallen tilbage til den gamle tilstand. Dette giver mening, da en 2.6-skal muligvis skal oprette forbindelse til og arbejde med ældre servere. Hvis du opretter forbindelse til en 2.4-server, vil dette blive taget hånd om for dig, men for at tvinge sagen til en bestemt forbindelse kan du køre:
db.getMongo().forceWriteMode("legacy");
Når du er færdig, kan du vende tilbage til 2.6-versionen med:
db1.getMongo().forceWriteMode("commands");
For faktisk brug, se mit crud.js snippet . Dette virker indtil videre, men kan fjernes uden varsel på ethvert tidspunkt i fremtiden og er virkelig ikke beregnet til omfattende brug, så brug på egen risiko.