Esta página proporciona orientación para seleccionar el almacenamiento para implementaciones autogestionadas de mongot (proceso de MongoDB Search y MongoDB Búsqueda Vectorial) en entornos bare-metal y virtualizados.
El rendimiento depende del sistema de almacenamiento completo (dispositivo, controlador, host, red y sistema de archivos). Valide la clase elegida bajo una carga representativa antes de implementarla en producción.
Por qué la clase de almacenamiento es importante para mongot
mongot se compila en Apache Lucene, que accede a los segmentos de índice a través de archivos asignados a la memoria y depende de lecturas aleatorias de baja latencia tanto para la entrega de query como para el mantenimiento del índice en segundo plano. La latencia de almacenamiento afecta a:
Latencia de query. Las fallas de caché se dirigen al disco en la ruta crítica de cada query.
Rendimiento de indexación y replicación. La fusión de segmentos, la sincronización inicial y la replicación leen segmentos existentes y guardan otros nuevos. Las suposiciones de solo guardar no se mantienen.
Estabilidad bajo carga. A medida que aumenta la presión de la caché del sistema de archivos, la latencia de las queries se degrada de forma no lineal con la latencia del almacenamiento.
Estas propiedades hacen de la clase de almacenamiento una de las decisiones de infraestructura de mayor impacto para una implementación mongot.
Resumen de recomendaciones
Utiliza un SSD NVMe local dedicado por defecto para el almacenamiento de índices
mongotde producción.Utilice SSD SATA o SAS (Serial Attached SCSI) de empresa local solo cuando NVMe no esté disponible y la carga de trabajo sea de pequeña a moderada.
Utilice una SAN totalmente flash solo cuando se presente como un dispositivo de bloque y se valide bajo una carga representativa de lectura y escritura mixtas.
No utilice:
NFS, NAS, SMB u otros protocolos de archivos compartidos
SSD en la nube de uso general como nivel de índice de producción
Cualquier medio giratorio
Orientación de clase de almacenamiento
La siguiente tabla resume la recomendación para cada clase de almacenamiento. Las bandas de latencia e IOPS reflejan puntos de referencia públicos generalizados para la clase. Su hardware podría ser diferente. Sus resultados podrían diferir.
Categoría | clase de almacenamiento | Banda de latencia de lectura aleatoria | Banda de IOPS de lectura aleatoria | Recomendación |
|---|---|---|---|---|
Recomendado | SSD PCIe/NVMe local | ~20-150 µs | 170K+ por dispositivo, escalado a 1M+ en unidades empresariales premium | Recomendado por defecto para producción. El más adecuado para el perfil de lectura aleatoria de Lucene. |
Condicional | SSD SATA/SAS de empresa local | ~100-200 µs | ~95K-100K por dispositivo | Línea de base aceptable para cargas de trabajo pequeñas a moderadas en volúmenes de datos dedicados. No recomendado para implementaciones sensibles a la latencia o con mucha indexación. |
Condicional | SAN totalmente flash, dispositivo de bloque (FC, iSCSI, NVMe-oF) | Submilisegundos bajo carga normal, aunque varía sustancialmente según el protocolo y la red | 200K+ en el arreglo, aunque el rendimiento en el mundo real depende de la ruta completa del host al arreglo | Solo es una segunda opción aceptable cuando se monta en bloque, es totalmente flash y se valida de extremo a extremo bajo una carga representativa. |
No recomendado | SSD en la nube de uso general (por ejemplo, niveles de SSD de red orientados al arranque) | Milisegundos de un solo dígito | Unos pocos miles de IOPS de referencia, escalando con el aprovisionamiento | Posicionado para el arranque, el desarrollo, las pruebas y el uso transaccional amplio. No apto para cargas de trabajo de lectura aleatoria de baja latencia. |
No recomendado | NFS, NAS, SMB u otros protocolos de archivos compartidos | Ver justificación | Ver justificación | Riesgo de corrección además del rendimiento: Lucene ha documentado fallas de bloqueo de archivos y coherencia de caché sobre NFS. No usar. |
No recomendado | HDD, HDD optimizado para rendimiento, HDD frío u otros medios magnéticos | 5-10 ms | 75-500 per volume | Significativamente más lento que los medios de clase SSD y fundamentalmente desajustado al patrón de acceso de Lucene. |
Supervise su elección de almacenamiento
Combine la selección de almacenamiento con la supervisión, especialmente si su clase de almacenamiento es diferente de NVMe local.
Investigar IOPS de disco sostenidas por encima de ~1K en el volumen del índice. La operación saludable no debe acercarse al punto de saturación del dispositivo.
Supervise los errores de página de búsqueda por encima de ~1000/s, ya que indican que el sistema operativo está extrayendo repetidamente las páginas de índice necesarias del disco en lugar de servirlas desde la caché del sistema de archivos. Junto con las IOPS elevadas, esto indica presión de almacenamiento o memoria en la ruta crítica.
Observe la latencia de la query p99 para detectar un crecimiento no lineal a medida que aumenta la carga. Las implementaciones vinculadas al almacenamiento se degradan bruscamente en lugar de gradualmente.
Si observa estas señales en una implementación SAN, de propósito general o SATA/SAS, revise la clase de almacenamiento antes de escalar. Si los ve en NVMe local, primero observe el margen de memoria para la caché del sistema de archivos y si el volumen está realmente dedicado a mongot.