example - mongodb tutorial
Mongo cuenta muy lento cuando hay millones de discos. (3)
Como dijo @Remon, count () tiene que escanear todos los documentos que coinciden con la consulta / filtro. Es O (n) donde n es el número de documentos que coincidirán con el índice, o el número de documentos en la colección si el campo no está indexado.
En tales casos, normalmente desea revisar su requerimiento. ¿Realmente necesita un número preciso para el resultado 10161684? Si la precisión es importante, debe mantener un contador separado para la consulta en particular.
Pero en la mayoría de los casos, la precisión no es importante. Es uno de los dos:
- No te importa si son 10 millones o 10.2 millones, pero el orden de magnitud es importante, es decir, te importa si son 8 millones o 10 millones.
- Solo te importa el número exacto si es pequeño. Es decir, está interesado en saber que hay 44 resultados o 72. Pero una vez que va más allá, digamos, 1000, puede decir "más de 1000 objetos" encontrados al usuario.
En mis aplicaciones, encontré que la segunda opción es lo que quiero. Por lo tanto, también limito la consulta count (), para que la cuenta se detenga cuando alcanza un límite. Al igual que:
db.datasources.find({nid: 19882}).limit(1000).count(true)
Para el usuario, muestro ''1000 o más resultados encontrados'' si el recuento es 1000, de lo contrario, muestro el número exacto.
En cuanto a la primera opción ... todavía no he pensado en una solución ordenada.
//FAST
db.datasources.find().count()
12036788
//SLOW
db.datasources.find({nid:19882}).count()
10161684
Índice en nid
¿Alguna forma de hacer más rápida la segunda consulta? (Está tomando unos 8 segundos)
Las consultas de recuento, indexadas o no, son lentas debido al hecho de que MongoDB aún tiene que realizar un recorrido completo por el árbol B para encontrar el número adecuado de documentos que coincidan con sus criterios. La razón de esto es que la estructura del árbol b de MongoDB no se "cuenta", lo que significa que cada nodo no almacena información sobre la cantidad de elementos en el nodo / subárbol.
El problema se informa aquí https://jira.mongodb.org/browse/SERVER-1752 y actualmente no existe una solución alternativa para mejorar el rendimiento que no sea el mantenimiento manual de un contador para esa colección que, obviamente, conlleva algunas desventajas.
También tenga en cuenta que la versión db.col.count () (por lo que no hay criterios) puede tomar un gran atajo y en realidad no realiza una consulta, por lo tanto es su velocidad. Dicho esto, no siempre informa el mismo valor que una consulta de recuento que debería devolver todos los elementos (no estará en entornos fragmentados con un alto rendimiento de escritura, por ejemplo). A debate para que sea o no un error. Creo que es.
Tenga en cuenta que en 2.3+ se introdujo una optimización significativa que debería (y lo hace) mejorar el rendimiento de los recuentos en campos indexados. Consulte: https://jira.mongodb.org/browse/SERVER-7745
Tiene que mirar a través de cada campo de cada documento para el segundo. Podrías indexar nid para que la cuenta sea más rápida.