Os documentos são armazenados em ordem natural
Os documentos são armazenados em ordem decrescente com base na data. Assim, a coleção tem 20140731 como primeiro documento.
A menos que você esteja usando uma coleção limitada, não há garantia para a ordenação de documentos em disco (também conhecido como ordem natural).
Exclusões e movimentações de documentos (quando um documento ultrapassa seu espaço de registro alocado) criam espaço na lista livre que será reutilizado.
Aqui está um exemplo rápido que deve demonstrar isso no
mongo
Concha:// Start with an empty database & collection
use demodb; db.dropDatabase(); db.order.drop()
// Add some test data
for (i=0; i<1000; i++) {
db.order.insert({'i': i})
}
// Looks like insertion order! (0..9)
db.order.find({}).limit(10);
// Pause 5s for effect :)
sleep(5000);
// Remove half the entries
db.order.remove({ i: { $lt: 500 }})
// Re-add the missing entries
for (i=0; i<500; i++) {
db.order.insert({'i': i})
}
// Not the entries you expected .. space from deleted records was reused
db.order.find({}).limit(10)
// Clean up demodb
db.dropDatabase()
Ordem dos resultados
Quando uso o comando find com filtros {$gte :20140720, $lte :20140731}, o mongodb retorna a consulta em ordem crescente do campo "date".
Se um índice for usado para uma consulta, os documentos serão retornados na ordem em que forem encontrados no índice. Você deve aproveitar isso ao construir seus índices para consultas comuns (consulte:Usar índices para classificar resultados de consulta).
FYI, um índice simples (por exemplo, em
{date:1}
) pode ser usado para retornar os resultados classificados em ordem crescente ou decrescente. Classificar por ObjectID
Se você estiver usando os ObjectIDs padrão do MongoDB para
_id
, você pode classificar por { _id: 1 }
para aproximar a ordem de inserção desde os primeiros 4 bytes do ObjectID
incorporar um carimbo de data/hora. Se você quiser usar isso para classificar uma consulta com base em date
e pedido de inserção aproximado, você garantiria um índice em {date:1, _id:1}
. Observe que
ObjectID
s são normalmente gerados pelo driver do cliente, portanto, se houver desvio de relógio em seus servidores de aplicativos (ou o _id
é criado algum tempo antes do documento ser inserido) o ObjectID
s pode não refletir estritamente a "ordem de inserção" vista pelo servidor. Se a precisão do pedido de inserção for muito importante, geralmente é possível gerar o _id
no lado do servidor (a abordagem varia dependendo do driver).