Esta sección responde preguntas de planificación críticas sobre su 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 simple/de palabras clave |
|
edgeGram (Autocompletar) |
|
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 el disco tendrá una sobrecarga adicional.
Gestionar el consumo de memoria para prevenir la inestabilidad
- Utilice 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
- 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". - 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 proporcionar rendimiento de escritura y mantenimiento:
Adapte los recursos a su ritmo de escritura
- Alta tasa 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. - 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 desencadena 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 fragmentación
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 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 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 realizar 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 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 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.