Si MongoDB tiene un talón de Aquiles, es el hecho de que solo admite escrituras de un solo subproceso y reducción de mapas de un solo subproceso.
Como siempre, hay compensaciones aquí. Las escrituras de subproceso único son la forma más sencilla de evitar problemas de bloqueo y minimizar la sobrecarga. De la misma manera, las reducciones de mapas de subprocesos múltiples son una excelente manera de bloquear sus datos. Por lo tanto, las reducciones de mapas de un solo subproceso en un sistema de producción son probablemente más fáciles y seguras.
Sin embargo, no estás sin herramientas aquí. MongoDB proporcionará un subproceso de escritura para cada instancia. Entonces, si fragmenta MongoDB, obtendrá un subproceso de escritura para cada fragmento.
Si desea múltiples índices en 2 mil millones de filas, querrá ver la fragmentación de todos modos. Algunas matemáticas rápidas aquí:MongoID es de 12 bytes. El índice en MongoID será 2B * 12 bytes =22GB+. Si ahora desea agregar dos índices más (incluso solo dos números enteros de 4 bytes), estamos hablando de 7,5 GB para cada uno.
Entonces, en las filas 2B, está hablando de tener más de 37 GB en índices (mínimo ). En la mayoría de los servidores de 8 núcleos, eso significa que ni siquiera podrá mantener sus índices en la memoria, y mucho menos los datos.
Entonces, si desea un rendimiento serio aquí, querrá comenzar a analizar la fragmentación. Solo basado en los números generales. FWIW, MySQL no sería más experto en el manejo de documentos 2B. Con tantos datos, realmente necesitará varios servidores para mantenerse al día con la carga.
