Join us at MongoDB.local London on 7 May to unlock new possibilities for your data. Use WEB50 to save 50%.
Register now >
Docs Menu
Docs Home
/ /

Construir una arquitectura multiinquilino para la MongoDB Vector Search

Puedes implementar la Multiarrendamiento con MongoDB Vector Search para que una única instancia de una aplicación sirva para múltiples inquilinos. Esta página describe las recomendaciones de diseño que se aplican específicamente a MongoDB Vector Search. Estas recomendaciones difieren de nuestro Recomendaciones de múltiples tenencias para Atlas.

Consulta las siguientes recomendaciones al diseñar una arquitectura multiinquilino para MongoDB Vector Search.

Importante

Esta orientación supone que se pueden ubicar los inquilinos en una sola VPC. De lo contrario, deberá mantener proyectos separados para cada inquilino, lo cual no recomendamos para MongoDB Vector Search.

Recomendamos almacenar todos los datos de los inquilinos en una sola colección, así como en una única base de datos y clúster. Puede distinguir entre inquilinos incluyendo un tenant_id campo dentro de cada documento. Este campo puede ser cualquier identificador único para el arrendatario, como un UUID o un nombre de arrendatario. Puede utilizar este campo como un pre-filtro en sus índices y queries de MongoDB Vector Search.

Este enfoque centralizado ofrece los siguientes beneficios:

  • Fácil de modelar y escalar.

  • Simplifica las operaciones de mantenimiento.

  • Enrutamiento eficiente de query mediante prefiltrado por tenant_id.

    Nota

    Se le garantiza que no atenderá a inquilinos que no coincidan con este filtro.

No recomendamos almacenar cada inquilino en una colección o base de datos diferente por las siguientes razones:

  • Impacto en el rendimiento: Este enfoque puede generar diferentes flujo de cambios cargas dependiendo del número de colecciones, lo que podría afectar negativamente el rendimiento y las capacidades de supervisión.

  • Sin aislamiento adicional: Las garantías de aislamiento de datos en Atlas se aplican a nivel de base de datos. El uso de colecciones separadas dentro de la misma base de datos no ofrece ningún beneficio adicional de aislamiento de datos. El uso de bases de datos independientes introduce complejidad operativa sin ventajas significativas de seguridad en la mayoría de los casos de uso.

En su lugar, utilice una sola colección para todos los inquilinos. Para ver un ejemplo de cómo migrar de un modelo de colección por inquilino a uno de colección única, consulte Migración desde un modelo de colección por inquilino.

Considera las siguientes estrategias para mitigar posibles problemas de rendimiento con el enfoque recomendado.

Si tiene muchos inquilinos con relativamente pocos vectores cada uno, o si experimenta problemas de rendimiento debido a una distribución desigual de los datos (algunos inquilinos grandes y muchos pequeños), considere las siguientes estrategias.

Si tiene muchos inquilinos (hasta 1 millones) y cada inquilino tiene relativamente pocos vectores (menos 10 de,000 vectores cada uno), utilice un flat índice en lugar del predeterminado Mundos pequeños navegables jerárquicosíndice. Para crear un índice plano, establezca el indexingMethod campo en flat en la definición de su índice.

Cuando cada inquilino tiene un número reducido de vectores, las consultas filtradas para un inquilino específico ya se han buscado exhaustivamente. En estos casos, el grafo de mundos pequeños navegables jerárquicos no aporta ningún beneficio, sino que genera una sobrecarga de memoria y mantenimiento. Los índices planos eliminan esta sobrecarga innecesaria.

Los índices planos ofrecen las siguientes ventajas para cargas de trabajo multiusuario:

  • Optimizado para filtros selectivos: Para consultas altamente selectivas donde cada inquilino tiene un número reducido de vectores, el escaneo exhaustivo ya es la ruta más rápida. Los índices planos lo admiten directamente, mejorando tanto la latencia como la recuperación.

  • Rendimiento predecible: la latencia de las consultas se mantiene dentro de un rango estrecho, independientemente del inquilino al que se dirija, lo que elimina los efectos de la interferencia entre inquilinos.

  • Eficiencia de recursos: Los índices planos eliminan la sobrecarga de memoria y mantenimiento asociada con la construcción de grafos de mundos pequeños navegables jerárquicos.

Ejemplo

La siguiente definición de índice crea un índice plano con un campo de filtro tenant_id:

{
"fields": [
{
"type": "vector",
"path": "<fieldToIndex>",
"numDimensions": <numberOfDimensions>,
"similarity": "euclidean | cosine | dotProduct",
"indexingMethod": "flat"
},
{
"type": "filter",
"path": "tenant_id"
}
]
}

Nota

Los índices planos son compatibles con la cuantización escalar y binaria. Incluya siempre el tenant_id campo como prefiltro en sus consultas cuando utilice índices planos.

Para inquilinos más grandes que tengan más 10 de,000 vectores cada uno, utilice índices de mundos pequeños navegables jerárquicos en las vistas de MongoDB para separar los inquilinos grandes de los inquilinos más pequeños:

  • Grandes inquilinos (Top 1%):

    • Crea una vista para cada inquilino grande.

    • Cree un índice jerárquico de mundos pequeños navegables para cada vista.

    • Mantén un registro de grandes inquilinos que verifiques en tiempo de query para dirigir las queries en consecuencia.

  • Pequeños inquilinos (inquilinos restantes):

    • Crear una vista única para todos los pequeños inquilinos.

    • Crea un índice plano único para esta vista.

    • Utiliza el campo tenant_id como pre-filtro para enrutar las consultas en consecuencia.

El siguiente ejemplo muestra cómo crear vistas para grandes y pequeños inquilinos usando mongosh:

Mantenga un registro de sus inquilinos grandes y sus valores tenant_id correspondientes y luego cree una vista para cada uno de estos inquilinos:

db.createView(
"<viewName>",
"<collectionName>",
[
{
"$match": {
"tenant_id": "<largeTenantId>"
}
}
]
)

Crear una vista para los pequeños inquilinos, excluyendo a los grandes inquilinos:

db.createView(
"<viewName>",
"<collectionName>",
[
{
"$match": {
"tenant_id": {
"$nin": [ "<largeTenantId1>", "<largeTenantId2>", ... ]
}
}
}
]
)

Después de crear las vistas, crea los índices para cada vista. Verifica lo siguiente:

  • Al especificar el nombre de la colección para el índice, utiliza el nombre de la vista en lugar del nombre original de la colección.

  • Para vistas de inquilinos grandes, cree un índice de Mundos Pequeños Navegables Jerárquicos (opción predeterminada).

  • Para la vista de inquilino pequeño, cree un índice con el método de indexación plana e incluya el tenant_id campo como un prefiltro.

Consulte la página Crear índices para obtener instrucciones sobre cómo crear índices.

Si tienes muchos tenants (arrendatarios) que cada uno tiene un gran número de vectores, considera usar un sistema basado en particiones distribuyendo los datos entre los fragmentos.

Puedes usar el campo tenant_id como llave de partición para distribuir los datos a través de rangos específicos basados en el ID de arrendatario. Para más información, consulta Particionado clasificado por rango.

Para migrar de un modelo de colección por inquilino a un modelo de colección única, procesa cada colección de inquilinos e inserta los documentos en una nueva colección.

Volver

Recomendaciones adicionales

En esta página