Esta sección responde preguntas críticas de planificación sobre tu mongot
implementación y proporciona pasos prácticos para diseñar tu arquitectura de búsqueda. Para obtener una visión general completa, lea esta sección de forma lineal. Alternativamente, puede utilizar esta sección como referencia, saltando 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 construir una implementación robusta.
Características e índices de datos
La estructura y la definición de índice de tus datos son los principales impulsores del uso de disco y los requisitos de RAM. Usa esta sección para estimar el tamaño final del índice y la memoria necesaria para administrar los índices de manera eficiente.
Calcula un tamaño de índice base
Utilice la siguiente fórmula como punto de partida para su estimación de 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 fundamental y depende en gran medida de tu estrategia de tokenización. Utiliza estos multiplicadores como guía:
Caso de uso | Multiplicador |
|---|---|
Tokenización estándar/por lenguaje |
|
Tokenización por palabras clave/simple |
|
edgeGram (autocompletado) |
|
nGram (coincidencia parcial) |
|
Nota
Los multiplicadores del factor de expansión anteriores representan un ejemplo generalizado y pueden no aplicarse a todos los contenidos basados en texto. Asegúrate de probar con tus propios datos para determinar el cálculo del índice para tu implementación.
Agregar tamaño de índice de vector
Para la búsqueda vectorial, calcula el tamaño del índice por separado y súmalo al total. El tamaño de datos vectoriales sin procesar es una referencia razonable para este valor.
Vector Index Size = (Total Number of Vectors) x (Vector Dimensions) x 4 bytes / dimension
Nota
Esta fórmula es para float32 vectores. El final
El índice HNSW en disco tendrá gastos en general.
Gestionar el consumo de memoria para prevenir la inestabilidad
- Utiliza asignaciones estáticas
- Si la estructura de tu documento es impredecible, desactiva los mapeos dinámicos. La asignación dinámica puede provocar una "explosión de asignación", en la que se crean miles de campos no deseados, consumiendo una cantidad excesiva de RAM y causando inestabilidad. Define explícitamente tu índice con
dynamic: false. Para saber más, consulta Mapeos dinámicos y estáticos. - Limitar campos de origen almacenados
- Sólo almacena el conjunto mínimo de campos requeridos para tus resultados de búsqueda dentro del propio índice
mongot. Obtener campos de la colección principal de MongoDB suele ser más eficiente y reduce el espacio en disco utilizado por el índice. Para obtener más información, consultar Definir campos fuente almacenados en tu índice de búsqueda de MongoDB. - Considerar funcionalidades de alta memoria
- Ten en cuenta que las colecciones de sinónimos y los documentos incrustados profundamente anidados generan artefactos de memoria significativos. Si utiliza en gran medida estas funcionalidades, debe asignar más espacio de pila de Java al proceso
mongot.
Carga de trabajo de indexación
La velocidad y el tipo de tus guardados (inserciones, actualizaciones, eliminaciones) determinan la CPU y las IOPS del disco necesarias para mantener tu índice de búsqueda sincronizado con tu base de datos.
Para prever el rendimiento de guardar y el mantenimiento:
Asocia los recursos a su tasa de escritura
- Alta tasa de escritura (> 1,000 operaciones por segundo)
- Esta carga de trabajo depende tanto de la CPU como del I/O. Provisiona servers with a high CPU count and fast almacenamiento. Supervise la utilización de la CPU y la longitud de la cola de E/S en disco del proceso
mongot. Si estas métricas son consistentemente altas y el atraso de la replicación está creciendo, necesitas escalar tu hardware. - Tasa de escritura baja (<100 operaciones por segundo)
- Las configuraciones de hardware estándar suelen ser suficientes.
Minimizar el atraso de la replicación
- Consolidar Índices
- Evita definir varios índices de búsqueda separados en una única colección. Cada índice añade gastos en general. En cambio, crea una sola definición de índice integral.
- Materializar Vistas Complejas
- Si estás indexando una vista compleja, el rendimiento del flujo de cambios puede ser una limitación. Considera crear un
vista materializada para proporcionar una fuente de datos simple y preagregada que
mongotpueda indexar.
Plan de reconstrucción de índices
Cambiar una definición de índice activa una reconstrucción completa que consume muchos recursos.
Una reconstrucción crea un nuevo índice además del antiguo, antes de cambiar las solicitudes de query al nuevo índice. Asegúrate siempre de tener al menos el 125% del tamaño actual de tu índice disponible como espacio libre en disco para llevar a cabo este proceso sin agotar el almacenamiento.
Escala horizontalmente con particionado
Para cargas de trabajo de escritura extremadamente exigentes, escalar un solo nodo mongot verticalmente podría no ser suficiente.
Si anticipa cargas de escritura sostenidas que superen 10,000 operaciones por segundo, el particionado es la estrategia de escalado más eficaz. Se necesita un mínimo de 1 mongot por partición. mongot sólo indexa las colecciones dentro de la partición al que está conectado, lo que ayuda a distribuir la carga de indexación de manera horizontal.
Query Carga de trabajo
El rendimiento de las consultas depende, principalmente, de la CPU para el procesamiento y de la RAM para el almacenamiento en caché. La complejidad y el volumen de sus consultas determinan los recursos necesarios para cumplir con sus objetivos de latencia.
Para estimar los tamaños de implementación necesarios para el rendimiento de query:
Estimar los núcleos de CPU necesarios
Para establecer una línea base de CPU, utiliza tu 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 agregaciones complejas, coincidencia difusa o consultas regex, el rendimiento puede oscilar entre 2y5 QPS por núcleo. Por el contrario, la simple coincidencia de términos podría arrojar 20+ QPS por núcleo. Siempre pruebe el rendimiento con una combinación realista de consultas.
Asignar RAM para baja latencia
La RAM es el factor más importante para consultas rápidas.
- Búsqueda de texto completo
- El objetivo es encajar la mayor parte posible del índice en la caché del sistema de archivos del sistema operativo. Para obtener un rendimiento óptimo, aprovisiona suficiente RAM en el nodo
mongotpara igualar el tamaño total del índice en el disco. Esto minimiza las lecturas lentas del disco. - Búsqueda vectorial
- Para la búsqueda vectorial de baja latencia, el índice del grafo HNSW debe estar en la memoria. Para calcular la RAM mínima requerida, use los pasos en el procedimiento de estimación del tamaño del índice y agregue un margen de 20-25% para imprevistos. Si el índice vectorial no cabe en la RAM, la latencia de query aumenta.
Nota
Para reducir los requisitos de memoria RAM, considera utilizar vector quantization. La cuantización vectorial puede comprimir incrustaciones vectoriales, lo que reduce su huella de memoria (y, por tanto, la RAM necesaria para albergarlas) con un impacto mínimo en la recuperación o precisión.