Puedes implementar multi-tenencia con MongoDB Search para que una sola instancia de una aplicación sirva a varios inquilinos. Esta página describe las recomendaciones de diseño que se aplican específicamente a MongoDB Search para estructurar los datos y los índices de MongoDB Search, con el fin de escalar de forma segura y mantener el aislamiento de los inquilinos.
Importante
Esta orientación asume que puedes ubicar inquilinos dentro de un solo VPC. Si se requiere un aislamiento estricto de la red, debes mantener proyectos separados para cada inquilino.
Elegir una estrategia
Selecciona una estrategia basada en tus necesidades de aislamiento, objetivos de escalado y requerimientos de carga de escritura. Las estrategias más comunes son:
Una sola colección para todos los inquilinos - Esta estrategia se recomienda para la mayoría de las cargas de trabajo.
Una base de datos por inquilino: esta estrategia ofrece un alto aislamiento, pero aumenta el conteo de índices.
Una Colección por inquilino - Esta estrategia no se recomienda para cargas de trabajo de búsqueda de MongoDB Search.
Una única colección para todos los inquilinos (recomendado)
Recomendamos aplicar la estrategia de una colección para todos los tenants. En esta arquitectura, se almacena toda la información de los arrendatarios en una sola colección dentro de una única base de datos. Puedes distinguir entre inquilinos incluyendo un campo tenant_id dentro de cada documento. Este campo puede ser cualquier identificador único para el inquilino, como un UUID o un nombre de inquilino.
Este enfoque centralizado ofrece los siguientes beneficios:
Reduce el número de índices
Como todos los datos del arrendatario se almacenan en una sola colección, solo necesitas un índice único que sirva documentos para todos los arrendatarios. Evita llegar a los límites de recursos del clúster. Por ejemplo, puedes incluir el
tenant_idy otros campos compartidos o específicos del inquilino en un único índice.Simplifica las operaciones de mantenimiento
Al tener solo una única colección que almacena todos los datos, no tienes que mantener varias colecciones ni escalar recursos entre varias bases de datos. También simplificas las operaciones de copia de seguridad, particionado y replicación, ya que solo necesitas dirigirte a una única colección en una única base de datos.
Procesa las consultas eficientemente
Proporciones el campo
tenant_iden tus consultas como un filtro utilizando el operador igual dentro de la cláusula$search.compound.filter.Nota
Tus resultados de query solo incluirán documentos del inquilino coincidente, lo que previene que los datos se filtren entre inquilinos.
Si los inquilinos que co-localizas comparten patrones de acceso y tamaños de recursos similares, esta estrategia también mantiene bajo el recuento de campos del índice Lucene.
Importante
Cuando cada inquilino tiene una alta carga de escritura, colocarlos todos en una sola colección puede crear una contención de escritura. En ese escenario, considera dividir los tenants con mayores escrituras en colecciones separadas para que puedas distribuir la carga de escritura entre más recursos subyacentes.
Si tienes inquilinos grandes con requisitos de recursos o indexación únicos, usa una Vista:
Indexar por separado. Crear un índice de búsqueda de MongoDB en la Vista.
Esto te permite personalizar la definición de índice para el gran inquilino sin afectar el índice compartido utilizado por otros. Todos los demás inquilinos pueden utilizar un único índice.
Un recuento elevado de índices genera una carga significativa en el clúster base y podría interrumpir su carga de trabajo. El número de índices que su clúster puede admitir depende de su nivel de clúster y la carga de trabajo. Los niveles de clúster más pequeños como
M10pueden experimentar degradación del rendimiento o errores de falta de memoria a medida que aumenta el recuento de índices. Empiece con un número reducido de índices y supervise el uso de recursos de su clúster a medida que escala.
Si actualmente aplica la estrategia de una colección por inquilino, recomendamos el escalado vertical del nivel base para evitar un mayor atraso de la replicación o errores de OOM debido a la contención de recursos por un gran número de índices. También recomendamos migrar a la estrategia de una colección para todos los inquilinos.
Manejo de inquilinos con un alto volumen de guardar
Si ciertos inquilinos tienen cargas de guardar masivas, podrían causar conflictos en una colección compartida. Recomendamos que solo se cambie a los inquilinos de mayor volumen a colecciones separadas para repartir la carga de E/S.
Gestión de Requerimientos Únicos (Vistas)
Si un tenancy requiere indexación única o es significativamente más grande que otros, utiliza una Visualización de MongoDB:
Crear una vista usando
$matchpara filtrar únicamente los documentos de ese inquilino.Crea un índice de búsqueda de MongoDB en esa Vista. Esto permite la personalización para inquilinos atípicos sin interrumpir el índice compartido utilizado por la mayoría.
Una base de datos por inquilino
En una configurar de base de datos por inquilino, cada inquilino contiene su propia base de datos. Este configurar aísla los datos de los inquilinos, pero también multiplica el número de índices en el clúster. A medida que aumenta el número de bases de datos de inquilinos, la cantidad de índices puede superar lo que su nivel de clúster y su carga de trabajo pueden soportar.
Advertencia
Un recuento elevado de índices genera una carga significativa en el clúster base y podría interrumpir su carga de trabajo. El número de índices que su clúster puede admitir depende de su nivel de clúster y la carga de trabajo. Los niveles de clúster más pequeños como M10 pueden experimentar degradación del rendimiento o errores de falta de memoria a medida que aumenta el recuento de índices. Empiece con un número reducido de índices y supervise el uso de recursos de su clúster a medida que escala.
Una colección por inquilino (no recomendado)
La estrategia de colección por inquilino asigna a cada inquilino su propia colección dentro de una base de datos compartida. Los gastos en general de mantener un índice por colección podría causar:
Aumento del atraso de la replicación
Errores de OOM debido a la contención de recursos
Inestabilidad en el nivel base
No recomendamos esta estrategia para MongoDB Search a menos que los tenants tengan cargas de trabajo muy predecibles y ligeras. Si actualmente utiliza esta estrategia, migre hacia la una colección para todos los inquilinos estrategia.
Gestión de campos indexados
Considera las siguientes recomendaciones para gestionar campos indexados: