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 alojamiento multiinquilino 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, debe mantener proyectos separados para cada inquilino, lo cual no recomendamos para MongoDB Vector Search.

Recomendamos almacenar todos los datos del inquilino en una única colección, así como en una única base de datos y clúster. Puedes distinguir entre inquilinos al incluir 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. Puede utilizar este campo como un Prefiltra en tus índices y consultas 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

    Tienes la garantía de no servir tenants 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 producir cargas de flujo de cambios variables según el número de colecciones, lo que podría afectar negativamente el rendimiento y las capacidades de supervisión.

  • No hay 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 proporciona ningún beneficio adicional de aislamiento de datos. El uso de bases de datos separadas introduce una complejidad operativa sin ventajas significativas en materia de seguridad para la mayoría de los casos de uso.

En su lugar, utiliza 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 un modelo de colección única, consulta Migrar de un modelo de colección por inquilino.

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

Si tienes muchos tenants con relativamente pocos vectores cada uno, o si experimentas problemas de rendimiento debido a la distribución desigual de datos (algunos tenants grandes y muchos pequeños), considera las siguientes estrategias.

Si tiene varios tenants (hasta 1 millones) y cada tenant tiene relativamente pocos vectores (menos de 10,000 vectores cada uno), utilice un índice flat en lugar del índice por defecto Hierarchical Navigable Small Worlds índice. Para crear un índice plano, establece el campo indexingMethod en flat en tu definición de índice.

Cuando cada inquilino tiene un pequeño número de vectores, las consultas filtradas para un inquilino específico ya se buscan de manera exhaustiva. En estos casos, el Mundo Navegable Jerárquico Reducido grafo no aporta ninguna ventaja, pero sí añade gastos generales de memoria y mantenimiento. Los índices planos eliminan estos gastos en general innecesarios.

Los índices planos ofrecen los siguientes beneficios para cargas de trabajo con múltiples inquilinos:

  • Optimizado para filtros selectivos: para consultas altamente selectivas donde cada inquilino tiene un pequeño número de vectores, el escaneo exhaustivo ya es la ruta más rápida. Los índices planos admiten esto directamente, lo que mejora tanto la latencia como el recall.

  • Desempeño predecible: La latencia de las query se mantiene en un rango estrecho, independientemente de qué inquilino sea el objetivo, eliminando los efectos de vecinos ruidosos entre los inquilinos.

  • Eficiencia de recursos: Los índices planos eliminan la sobrecarga de memoria y mantenimiento asociada con la creación de Mundos Pequeños Navegables Jerárquicos grafos.

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 cuantificación escalar y binaria. Incluye siempre el campo tenant_id como un previo filtro en tus consultas cuando utilices índices planos.

Para inquilinos grandes que tengan más de 10,000 vectores cada uno, utilice Mundos Pequeños Navegables Jerárquicos índices en Vistas de MongoDB para separar los grandes inquilinos de los más pequeños:

  • Grandes inquilinos (Top 1%):

    • Crea una vista para cada inquilino grande.

    • Cree un Mundos Pequeños Navegables Jerárquicos índice 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.

    • Construye 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:

Mantén un registro de tus grandes inquilinos y sus respectivos valores de tenant_id, y luego crea 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 Pequeños mundos navegables jerárquicos índice (el por defecto).

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

Consulta 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