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 supone que se pueden ubicar los inquilinos en una sola 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 - Este estrategia es recomendada 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 diferenciar entre arrendatarios incluyendo un tenant_id campo 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
Se proporciona el campo
tenant_iden las consultas como 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:
Aísle un inquilino. Crea una vista utilizando una
$matchcon una operación$exprpara filtrar solo los documentos del inquilino.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 conteo alto de índices genera una carga significativa en el clúster base y podría interrumpir tu carga de trabajo. El límite estricto para los índices de búsqueda en un solo clúster es 2,500. Sin embargo, el número de índices que puede admitir tu clúster depende del nivel de tu clúster y de la carga de trabajo. Niveles de clúster más pequeños, como
M10, podrían experimentar una degradación del rendimiento o errores de falta de memoria con muchos menos índices. Empieza con un pequeño número de índices y supervisa el uso de recursos de tu clúster a medida que escalas.
If you currently apply the one collection per tenant strategy, we recommend scaling up the base tier to prevent increased replication lagor OOM errors due to resource contention from ahigh number of indexes. We also recommend migrating to the one collection for all tenants strategy.
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 arrendatario requiere indexación única o es significativamente más grande que otros, utiliza una Vista 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 configuración de base de datos por inquilino, cada inquilino contiene su propia base de datos. Esta configuración aísla los datos de los arrendatarios, pero también multiplica la cantidad de índices en el clúster. Si hay más de 2,500 bases de datos dando soporte a todos los inquilinos, el clúster podría llegar al límite de índice de 2,500.
Advertencia
Un conteo alto de índices genera una carga significativa en el clúster base y podría interrumpir tu carga de trabajo. El límite estricto para los índices de búsqueda en un solo clúster es 2,500. Sin embargo, el número de índices que puede admitir tu clúster depende del nivel de tu clúster y de la carga de trabajo. Niveles de clúster más pequeños, como M10, podrían experimentar una degradación del rendimiento o errores de falta de memoria con muchos menos índices. Empieza con un pequeño número de índices y supervisa el uso de recursos de tu clúster a medida que escalas.
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 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:
Las aplicaciones multicliente a menudo requieren campos personalizados por inquilino que se puedan buscar, clasificar, facetar y filtrar. Usa un typeSet para indizar dinámicamente subcampos de un path para que MongoDB Search detecte nuevos campos automáticamente sin una reconstrucción completa del índice. Evite indexar estos campos de forma estática, ya que hacerlo provoca una reconstrucción que aumenta la presión en la CPU y puede consumir hasta 2veces el espacio en disco del índice.
Nota
Riesgo Demasiados campos
Lucene index performance can degrade if there are more than 1000 distinct fields. You can monitor the number of unique fields in the MongoDB Search index in the MongoDB Search metrics. If you need to support one thousand or more fields, we recommend the following:
Separar un subconjunto de inquilinos en un índice separado mediante View, de modo que el número distinto de campos existentes en un único índice Lucene siga siendo inferior a mil.
Limitar el número de campos que un solo inquilino puede añadir.
Si utilizas el patrón de atributo para almacenar diferentes claves por tenant, te recomendamos que hagas lo siguiente:
Aplanar el arreglo incrustado de documentos usando una Vista.
Crea un índice de búsqueda de MongoDB en la vista, que se almacena en el disco.
Si no se aplana el arreglo de documentos, será necesario utilizar de operadores embeddedDocuments (similares a $elemMatch) para consultar los atributos, lo cual es menos eficiente que consultar una estructura aplanada.