Esta sección responde preguntas de planificación críticas sobre su mongot
Implementación y proporciona pasos prácticos para diseñar su arquitectura de búsqueda. Para obtener una visión general completa, lea esta sección de forma lineal. También puede usar esta sección como referencia y pasar a las secciones relevantes según sea necesario. El objetivo de esta sección es ayudar a estimar con precisión los requisitos de recursos y a construir una implementación robusta.
Características de los datos e índices
La estructura de sus datos y la definición del índice son los principales factores que determinan el uso del disco y los requisitos de RAM. Utilice esta sección para estimar el tamaño final del índice y la memoria necesaria para gestionar los índices eficientemente.
Calcula un tamaño de índice base
Utilice la siguiente fórmula como punto de partida para estimar el espacio en disco:
Estimated Index Size = (Number of Documents) x (Avg. Size of Indexed Text per Doc) x (Expansion Factor)
El factor de expansión es crucial y depende en gran medida de su estrategia de tokenización. Utilice estos multiplicadores como guía:
Caso de uso | Multiplicador |
|---|---|
Tokenización estándar/por lenguaje |
|
Tokenización simple/de palabras clave |
|
edgeGram (Autocompletar) |
|
nGram (coincidencia parcial) |
|
Nota
Los multiplicadores de factores de expansión anteriores representan un ejemplo general y podrían no aplicarse a todo el contenido de texto. Asegúrese de realizar pruebas con sus propios datos para determinar el cálculo del índice para su implementación.
Agregar tamaño de índice de vector
Para la búsqueda vectorial, calcule el tamaño del índice por separado y añádalo al total. El tamaño de los datos vectoriales sin procesar es un valor de referencia razonable.
Vector Index Size = (Total Number of Vectors) x (Vector Dimensions) x 4 bytes / dimension
Nota
Esta fórmula es para vectores float32. El resultado final
El índice HNSW en el disco tendrá una sobrecarga adicional.
Gestionar el consumo de memoria para prevenir la inestabilidad
- Utilice asignaciones estáticas
- Si la estructura de su documento es impredecible, desactive las asignaciones dinámicas. La asignación dinámica puede provocar una explosión de asignaciones, donde se crean miles de campos no deseados, consumiendo RAM excesiva y causando inestabilidad. Defina explícitamente su índice
dynamic: falsecon. Para obtener más información, consulte Asignaciones dinámicas y estáticas. - Limitar los campos de origen almacenados
- Almacene únicamente el conjunto mínimo de campos requeridos para los resultados de búsqueda dentro del
mongotíndice. Obtener campos de la colección principal de MongoDB suele ser más eficiente y reduce el espacio de disco que utiliza el índice. Para obtener más información, consulte "Definir campos de origen almacenados en el índice de búsqueda de MongoDB". - Tenga en cuenta las funciones de alta memoria
- Tenga en cuenta que las colecciones de sinónimos y los documentos embebidos profundamente anidados generan artefactos de memoria significativos. Si utiliza estas funciones con frecuencia, deberá asignar más espacio del montón de Java al
mongotproceso.
Carga de trabajo de indexación
La velocidad y el tipo de sus escrituras (inserciones, actualizaciones, eliminaciones) determinan las IOPS de CPU y disco necesarias para mantener su índice de búsqueda sincronizado con su base de datos.
Para proporcionar rendimiento de escritura y mantenimiento:
Adapte los recursos a su ritmo de escritura
- Alta velocidad de escritura (>1,000 operaciones por segundo)
- Esta carga de trabajo está limitada por la CPU y la E/S. Aprovisione servidores con un alto número de CPU y almacenamiento rápido. Supervise el uso de la CPU del proceso
mongoty la longitud de la cola de E/S del disco. Si estas métricas se mantienen altas y el retraso de replicación aumenta, deberá ampliar su hardware. - Baja velocidad de escritura (<100 operaciones por segundo)
- Las configuraciones de hardware estándar suelen ser suficientes.
Minimizar el retraso de replicación
- Consolidar índices
- Evite definir varios índices de búsqueda independientes en una misma colección. Cada índice supone una sobrecarga. En su lugar, cree una definición de índice única y completa.
- Materializar vistas complejas
- Si está indexando una vista compleja, el rendimiento del flujo de cambios puede ser una limitación. Considere crear un
vista materializada para proporcionar una fuente de datos simple y preagregada para
mongotque indexe.
Plan para la reconstrucción de índices
Cambiar una definición de índice desencadena una reconstrucción completa que consume muchos recursos.
Una reconstrucción crea un nuevo índice además del anterior antes de transferir las consultas al nuevo índice. Asegúrese siempre de tener al menos el 125% del tamaño actual del índice disponible como espacio libre en disco para realizar este proceso sin agotar el almacenamiento.
Escala horizontalmente con fragmentación
Para cargas de trabajo de escritura extremadamente exigentes, escalar un solo nodo mongot verticalmente podría no ser suficiente.
Si prevé cargas de escritura sostenidas superiores a 10,000 operaciones por segundo, la fragmentación es la estrategia de escalado más eficaz. Necesita un mínimo de 1 mongot por fragmento. mongot solo indexa las colecciones dentro del fragmento al que está conectado, lo que ayuda a distribuir la carga de indexación horizontalmente.
Carga de trabajo de consultas
El rendimiento de las consultas depende principalmente del uso de la CPU para el procesamiento y de la RAM para el almacenamiento en caché. La complejidad y el volumen de las consultas determinan los recursos necesarios para alcanzar los objetivos de latencia.
Para estimar los tamaños de implementación necesarios para el rendimiento de las consultas:
Estimar los núcleos de CPU necesarios
Para establecer una línea base de CPU, utilice su objetivo de consultas por segundo (QPS). Un punto de partida general es 1 núcleo de CPU por cada 10 QPS.
Esta línea base asume consultas simples. Para cargas de trabajo con muchas agregaciones complejas, coincidencias difusas o consultas de expresiones regulares, es posible que solo se alcancen de 2a5 QPS por núcleo. Por el contrario, una coincidencia de términos simple podría generar más de 20QPS por núcleo. Pruebe siempre el rendimiento con una combinación de consultas realista.
Asignar RAM para baja latencia
La RAM es el factor más importante para realizar consultas rápidas.
- Búsqueda de texto completo
- El objetivo es que la mayor parte posible del índice quepa en la caché del sistema de archivos del sistema operativo. Para un rendimiento óptimo, proporcione suficiente RAM en el nodo
mongotpara que coincida con el tamaño total del índice en el disco. Esto minimiza las lecturas lentas del disco. - Búsqueda vectorial
- Para una búsqueda vectorial de baja latencia, el índice del grafo HNSW debe existir en memoria. Para calcular la RAM mínima requerida, siga los pasos del procedimiento de estimación del tamaño del índice y agregue un búfer del 20-25% para la sobrecarga. Si el índice del vector no cabe en la RAM, la latencia de la consulta aumenta.
Nota
Para reducir los requisitos de RAM, considere usar la cuantificación vectorial. Esta puede comprimir las incrustaciones vectoriales, lo que reduce su consumo de memoria (y, por lo tanto, la RAM necesaria para almacenarlas), a menudo con un impacto mínimo en la recuperación o la precisión.