Aggiungi anche un po' di più a baloo la risposta.
Sul timestamp rispetto al numero lungo. Generalmente il server MongoDB non vedrà alcuna differenza. La lunghezza della codifica BSON è la stessa (64 bit). È possibile che vengano visualizzate prestazioni diverse sul lato client a seconda della codifica del driver. Ad esempio, sul lato Java, utilizzando il driver 10gen, viene visualizzato un timestamp come Date è molto più pesante di Long . Ci sono driver
che cercano di evitare quel sovraccarico.
L'altro problema è che vedrai un miglioramento delle prestazioni se chiudi l'intervallo per il primo campo dell'indice. Quindi se usi l'indice suggerito da baloo :
db.collection.ensureIndex({start: 1, final: 1})
La tua query funzionerà (potenzialmente molto) meglio se la query è:
db.collection.find({start:{$gt:DateTime(...),$lt:DateTime(...)},
final:{$lt:DateTime(...)}})
Concettualmente, se si pensa agli indici come a un albero, l'intervallo chiuso limita entrambi i lati dell'albero anziché solo un lato. Senza l'intervallo chiuso il server deve "controllare" tutte le voci con un start maggiore del timestamp fornito poiché non conosce la relazione tra start e final .
Potresti anche scoprire che le prestazioni della query non sono migliori utilizzando un singolo indice di campo come:
db.collection.ensureIndex({start: 1})
La maggior parte dei risparmi proviene dalla potatura del primo campo. Il caso in cui questo non sarà il caso è quando la query è coperta dall'indice o l'ordinamento/ordinamento dei risultati può essere derivato dall'indice.
HTH - Rob.
