Evitando desempenho de inserção lento com o shell MongoDB 2.6

Com a versão 2.6 do MongoDB, o comportamento do shell padrão mudou. Anteriormente, com 2.4 e abaixo, um loop for rápido e sujo para inserir 100.000 registros teria verificado apenas o status da última operação no loop. Isso é rápido, mas não exatamente o que você gostaria para um comportamento padrão em geral. Não há feedback se 999.999 inserções falharem, mas a última for bem-sucedida (não é um caso comum, admitido, mas você entendeu).

Como uma comparação rápida, aqui estão as velocidades relativas para este loop que faz 100.000 inserções:

2,4 = 2,246 segundos
2,6 = 37,169 segundos

Ai! Mas, como eu disse, este é um padrão melhor em geral, então podemos perdoar a versão 2.6, contanto que haja uma maneira de voltar ao desempenho de ~ 2 segundos. Existem 2 maneiras de fazer isso, a primeira é simplesmente usar o shell 2.4, que retornará ao comportamento antigo por padrão, mas isso tem desvantagens e é irritante ter que manter várias versões para algo assim.

A segunda maneira é a melhor daqui para frente – usar a nova API de inserção em massa não ordenada nos leva de volta a 2.246 segundos e, melhor ainda, nos dá feedback real sobre o que deu certo e o que falhou:

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" : [ ]
    })

Tudo isso pode ser executado como um comando de linha única, eu apenas divido para ajudar na legibilidade. Você pode ver os resultados completos do teste e a descrição completa disso nas perguntas e respostas do Stack Overflow que escrevi ou em minha postagem original do blog sobre o assunto