Hay muchos factores que limitan el rendimiento de las exportaciones.
- El tamaño de los datos es relativamente grande en comparación con la memoria disponible:~2 TB frente a ~5 GB de caché WiredTiger (si está configurado de forma predeterminada). Eso es:
- Todo el caché de WiredTiger solo puede contener en el mejor de los casos ~0.22% de la colección, en realidad es muy probable que sea mucho menos que esto, ya que el caché contendría datos de otras colecciones e índices.
- Esto significa que WiredTiger necesita buscar desde el disco con mucha frecuencia, mientras expulsa el contenido actual del caché. Si el conjunto de réplicas se está utilizando de forma activa, esto significaría expulsar los datos "sucios" de la memoria caché y conservarlos en el disco, lo que llevaría tiempo.
- Tenga en cuenta que los documentos dentro de la caché de WiredTiger no están comprimidos.
- La colección contiene documentos grandes, de los cuales solo necesita una parte. Esto significa que se requiere más tiempo para procesar los documentos.
- La colección está comprimida con zlib, lo que significa que se debe usar tiempo adicional para descomprimir los documentos.
- La preferencia de lectura es
secondaryPreferred, lo que significa que intentará leer desde un secundario. Si se escribe activamente en el conjunto de réplicas, las operaciones de aplicación de oplog en el secundario bloquearán los lectores. Esto agregará más retrasos.
Una posible mejora es que si esta es una operación que realiza con frecuencia, cree un índice en los campos relevantes y exportelo usando un consulta cubierta podría mejorar el rendimiento ya que el índice sería más pequeño que los documentos completos.
Editar:Ejecutando mongoexport en paralelo puede ser útil en este caso:
Además de la información adicional proporcionada, realicé una prueba que parece aliviar un poco este problema.
Parece que ejecutar mongoexport en paralelo, donde cada mongoexport manejar un subconjunto de la colección podría acelerar la exportación.
Para ello, divide el _id espacio de nombres correspondiente al número de mongoexport proceso que planea ejecutar.
Por ejemplo, si tengo 200.000 documentos, comenzando con _id:0 a _id:199,999 y usando 2 mongoexport procesos:
mongoexport -q '{"_id":{"$gte":0, "$lt":100000}}' -d test -c test > out1.json &
mongoexport -q '{"_id":{"$gte":100000, "$lt":200000}}' -d test -c test > out2.json &
donde en el ejemplo anterior, los dos mongoexport cada uno de los procesos maneja la mitad de la colección.
Probando este flujo de trabajo con 1 proceso, 2 procesos, 4 procesos y 8 procesos llego a los siguientes tiempos:
Usando 1 proceso:
real 0m32.720s
user 0m33.900s
sys 0m0.540s
2 procesos:
real 0m16.528s
user 0m17.068s
sys 0m0.300s
4 procesos:
real 0m8.441s
user 0m8.644s
sys 0m0.140s
8 procesos:
real 0m5.069s
user 0m4.520s
sys 0m0.364s
Dependiendo de los recursos disponibles, ejecutar 8 mongoexport procesos en paralelo parece acelerar el proceso por un factor de ~6. Esto fue probado en una máquina con 8 núcleos.
Nota :la respuesta de Halfer es similar en idea, aunque esta respuesta básicamente trata de ver si hay algún beneficio en llamar a mongoexport en paralelo.
