sql >> Base de Datos >  >> NoSQL >> MongoDB

El índice grande de MongoDB se construye muy lento

Concepciones erróneas

Velocidad

Incluso cuando no se habla de un índice de clave múltiple, esto es lo que sucede. Se está realizando un escaneo masivo de la tabla. Entonces, mongoDB itera sobre los documentos, intenta encontrar el campo que se indexará, evalúa ese campo (a null si no existe en el documento actual) y escribe sus hallazgos en no menos de 6 archivos, ya que estamos hablando de 6 índices. Haciendo los cálculos:200.000.000 / 86400 * 5 nos dice que mongoDB hace esto para aproximadamente 460 documentos por segundo o solo necesita 2,2 milisegundos por documento . Yo no llamaría a eso lento. Puede llevar mucho tiempo, pero no es lento.

{background:true}

Usar este parámetro no bloquearlo fuera de las bases de datos. Todo lo contrario, lo que se indica claramente en los documentos, tanto en el sección Creación de índice y en la sección de tutorial sobre la creación de índices en segundo plano . Sin embargo, hay una oración que puede malinterpretarse fácilmente:

Lo que eso significa es que no puede realizar operaciones que se aplican a todas las bases de datos y requieren un bloqueo de lectura o escritura.

Formas de mejorar (en el futuro)

Clúster fragmentado

Utilice un clúster compartido con fragmentos de conjuntos de réplicas. Es fácil de configurar y tiene múltiples ventajas además de un mejor rendimiento. Uno de ellos es la fácil escalabilidad que agrega un fragmento (y, por lo tanto, agrega espacio y potencia de cómputo a un clúster) es muy fácil. Las copias de seguridad tienen menos impacto en la aplicación. Ya no existe un único punto de falla (cuando se hace correctamente, esto se aplica incluso a las interrupciones en la escala de un centro de datos completo).

Usar un sistema de archivos diferente

Lo siento, ejecutar una aplicación dependiente del rendimiento de disco io en un servidor de Windows no tiene ningún sentido para mí, en absoluto. ExtFS4 o XFS son entre un 25 % y un 40 % más rápidos que NTFS o ReFS, según la optimización. Esto hace un real diferencia en las aplicaciones que dependen de E / S del disco como su caso de uso. Estamos hablando de una cuestión de días (sin tener en cuenta el mapeo de memoria más eficiente y el consumo de memoria reducido del sistema operativo en los sistemas Linux).

{background:true}

Si bien esto realmente no mejora el rendimiento (en realidad, la creación de índices en segundo plano lleva más tiempo que en primer plano por razones obvias), su aplicación permanece disponible durante el tiempo durante el cual se crea el índice. Entonces, dependiendo de sus necesidades, esta puede ser una opción viable.

Nota al margen :Es una Mala Idea™ , para escalar verticalmente al usar mongoDB, ya que fue diseñado explícitamente para escalar horizontalmente. Esto se aplica especialmente a grandes colecciones como la suya, ya que el procesamiento paralelo mejoraría enormemente el rendimiento de su aplicación.