Implemente MongoDB Search y búsqueda vectorial

El soporte para desplegar MongoDB Search y MongoDB Vector Search usando el operador de Kubernetes está disponible como una funcionalidad en vista previa. La funcionalidad y la documentación correspondiente pueden cambiar en cualquier momento durante el periodo de Vista Previa. Para aprender más, consulta Funcionalidades de Previsualización.

Puedes implementar MongoDB Search y búsqueda vectorial en tu clúster de Kubernetes para construir potentes experiencias de búsqueda directamente en tus aplicaciones. Utilizando MongoDB Search y Vector Search, puedes crear tanto funciones tradicionales de búsqueda de texto como funciones de búsqueda vectorial impulsadas por IA que se sincronizan automáticamente con una base de datos MongoDB on-premises. Esto elimina la necesidad de mantener sistemas separados sincronizados, al tiempo que se ofrece funcionalidades avanzadas de búsqueda. Para obtener más información, consulte:

Para habilitar las capacidades de búsqueda, como búsqueda full-text y búsqueda semántica en implementaciones on-prem, debe desplegar el proceso MongoDB Search y búsqueda vectorial (mongot) y conéctelo con su implementación de la base de datos MongoDB (mongod). La implementación de mongot es opcional y solo es necesario si planeas aprovechar las funcionalidades de búsqueda que ofrece.

Los procesos de la base de datos MongoDB (mongod) actúan como el proxy para todas las consultas de búsqueda para mongot. El mongod reenvía la query al mongot, que procesa la query. El mongot devuelve los resultados de la query al mongod, que luego te envía los resultados a ti. Nunca interactúas directamente con el mongot.

Cada proceso mongot tiene su propio volumen persistente que no se comparte ni con la base de datos ni con otros nodos de búsqueda. El almacenamiento se utiliza para mantener índices que se compilan a partir de los datos obtenidos continuamente de la base de datos. Las definiciones del índice (metadatos) se almacenan en la propia base de datos.

El mongot realiza las siguientes acciones:

Gestiona el índice.
El mongot es responsable de actualizar las definiciones de índices en la base de datos.
Obtiene los datos de la base de datos.
Los nodos mongot establecen conexiones permanentes con la base de datos para actualizar los índices en tiempo real.
Procesa consultas de búsqueda.
Cuando mongod recibe $search una consulta, o, la dirige$searchMeta a uno de los $vectorSearch mongot nodos. El mongot nodo que recibe la consulta la procesa, agrega los datos y devuelve los resultados mongod a, que a su vez los reenvía al usuario.

Los componentes mongot están estrechamente acoplados a un único set de réplicas de MongoDB y no pueden compartirse entre varias bases de datos o sets de réplicas. Eso significa que una implementación de conjunto de réplicas tiene sus propios nodos de búsqueda dedicados.

La conectividad de red entre mongot y mongod va en ambas direcciones:

mongot establece la conexión con el set de réplicas para obtener los datos que se utilizarán en la creación de índices y la ejecución de queries.
mongod se conecta a mongot para reenviar operaciones relacionadas con la búsqueda, como la gestión de índices y la consulta de datos.

MongoDB Search and búsqueda vectorial implementación

No hay muchas diferencias entre la arquitectura de implementación de búsqueda con o sin el Operador de Kubernetes. El Operador de Kubernetes simplifica los pasos necesarios para implementar nodos de búsqueda totalmente funcionales, especialmente cuando la base de datos también es gestionada por el Operador de Kubernetes.

Para implementar, aplica el Recurso Personalizado (CR) MongoDBSearch, que el Operador de Kubernetes recoge y comienza a desplegar pods mongot y solicita el almacenamiento persistente especificado en el spec. La MongoDB Search y la búsqueda vectorial implementadas mediante el Operador de Kubernetes pueden dirigirse tanto al set de réplicas de MongoDB implementado por el Operador de Kubernetes dentro del mismo clúster de Kubernetes como a una base de datos MongoDB externa totalmente independiente. Para aprender cómo implementar y configurar mongot para su uso:

Un set de réplicas de MongoDB en Kubernetes, consulte Instala y usa Búsqueda con MongoDB Enterprise Edition
Un set de réplicas de MongoDB externo, consulta Instala y usa MongoDB Search y búsqueda vectorial con MongoDB Enterprise Edition.

prerrequisitos

Para aprovechar MongoDB Search y la Búsqueda Vectorial en tu implementación de MongoDB Enterprise, debes contar con lo siguiente:

MongoDB completamente funcional 8.0.14+ set de réplicas implementado de una de las siguientes maneras:
- Dentro de un clúster de Kubernetes utilizando el Operador de Kubernetes
- Fuera de un clúster de Kubernetes
Instancia de Cloud Manager u Ops Manager

Antes de comenzar, tenga en cuenta lo siguiente:

Considerations

Se describen los requisitos de almacenamiento, red, recursos, versión y compatibilidad de Kubernetes, namespaces y RBAC, así como los requisitos de DNS del clúster.

Debe tener un StorageClass funcionando para la creación de volúmenes persistentes en el clúster de|k8s|. Sin esto, tu PersistentVolumeClaims podría quedar pendiente y MongoDB podría no tener almacenamiento duradero.
Debe tener una red de clúster correctamente configurada. Servicios como ClusterIP, NodePort o LoadBalancer deben poder enrutar el tráfico. Si los clientes externos necesitan acceso, configura un Ingress o un balanceador de carga.
Tus nodos de base de datos y de búsqueda deben tener suficiente CPU, memoria y espacio en disco asignados porque la base de datos de MongoDB y las cargas de trabajo de MongoDB Search y búsqueda vectorial requieren muchos recursos. Recomendamos utilizar solicitudes y límites en tus especificaciones de Pod para evitar la expulsión o la limitación.
Su versión de Kubernetes debe ser compatible con el operador de MongoDB o el Helm gráfica que desee utilizar. Algunos CRD o API difieren según la versión. Para obtener más información, consulta Controladores de MongoDB para compatibilidad con operadores de Kubernetes.
Debe crear cualquier Roles de RBAC y uniones de roles para que el Operador de Kubernetes y los procesos que se ejecutan dentro de los Pods puedan gestionar los recursos.

Limitaciones

Describe limitaciones al implementar MongoDB Search y búsqueda vectorial.

No puedes implementar MongoDB Search y Búsqueda Vectorial en las siguientes arquitecturas:

IBM Power (ppc64le)
IBM Z (s390x)

Tareas de configuración

La siguiente tabla muestra las tareas de configuración que el Operador de Kubernetes realiza automáticamente y las acciones que debe realizar para implementar con éxito MongoDB Search y búsqueda vectorial en Kubernetes y conectarse a un set de réplicas de MongoDB en Kubernetes o a un set de réplicas externo de MongoDB.

Tarea	(Inside Kubernetes) Performed by	(External MongoDB) Performed by
Implementa Ops Manager dentro de Kubernetes	Operador de Kubernetes	Operador de Kubernetes
Implementa Cloud Manager u Ops Manager fuera de Kubernetes	Tú	Tú
Implementa un set de réplicas de MongoDB	Operador de Kubernetes	Tú
Crea `MongoDBSearch` recursos personalizados	Tú	Tú
Proporciona la cadena de conexión al set de réplicas de MongoDB	Operador de Kubernetes	Tú
Crea configuración de `mongot` YAML	Operador de Kubernetes	Operador de Kubernetes
Configura los parámetros necesarios del set de réplicas en cada proceso `mongod`	Operador de Kubernetes	Tú
Polyfill `searchCoordinator` rol en MongoDB versión inferior a 8.2	Operador de Kubernetes	Tú
Crea un usuario para `mongot` con el `searchCoordinator` rol	Kubernetes operador y usted aplicando el recurso MongoDBUser	Tú
Configura el set de réplicas de MongoDB con un usuario que tenga los permisos necesarios para consultar query	Tú	Tú
Crea índices de búsqueda de MongoDB y Vector Search	Tú	Tú
Exponga los pods de búsqueda externamente para conectar desde cada nodo `mongod`	No es necesario	Tú
Expón los pods mongod de forma externa para conectarte desde los nodos `mongot`	No es necesario	Tú

Tanto mongod como mongot implementados en Kubernetes

Arquitectura de los procesos mongod y mongot ejecutándose en un clúster de Kubernetes.

El siguiente diagrama muestra la arquitectura de implementación de una instancia única de MongoDB Search y búsqueda vectorial con un set de réplicas de MongoDB Enterprise en un clúster de Kubernetes.

Diagrama que muestra la arquitectura de implementación de MongoDB Search y búsqueda vectorial con MongoDB Enterprise en un clúster de Kubernetes.

haga clic para ampliar

El siguiente diagrama muestra los componentes que el Operador de Kubernetes implementa en un clúster de Kubernetes para MongoDB Search y Búsqueda Vectorial con un set de réplicas de MongoDB Enterprise Edition.

Diagrama que muestra los componentes incluidos en el set de réplicas de MongoDB Enterprise con la implementación de MongoDB Search y búsqueda vectorial utilizando el operador.

haga clic para ampliar

Cuando tanto los procesos mongot como mongod se implementan dentro del clúster de Kubernetes, el operador de Kubernetes realiza la configuración de ambos procesos automáticamente. Concretamente, Kubernetes Operador realiza las siguientes operaciones:

Encuentra el MongoDB CR referenciado por MongoDBSearch utilizando spec.source.mongodbResourceRef, o mediante una convención de nomenclatura buscando un MongoDB CR con el mismo nombre que MongoDBSearch.
Genera la configuración mongot en un archivo YAML y la guarda en un config map llamado <MongoDBSearch.metadata.name>-search-config.
El mapa de configuración lo montan los pods de búsqueda y la configuración YAML es utilizada por el proceso de mongot al iniciar. El YAML generado contiene toda la información sobre cómo conectarse al set de réplicas, configuraciones de TLS y así sucesivamente.
Despliega el conjunto con estado de MongoDB Search y búsqueda vectorial llamado <MongoDBSearch.metadata.name>-search con los requisitos de almacenamiento y recursos configurados de acuerdo con la configuración de spec.persistence y spec.resourceRequirements en el CR.
Actualiza la configuración de cada proceso mongod agregando las opciones setParameter necesarias, incluidos los nombres de host y números de puerto de los hosts mongot. opciones setParameter necesarias, incluidos los nombres de host y los números de puerto de los miembros del set de réplicas de MongoDB.
Para MongoDB versiones anteriores a v8.2, crea el rol personalizado searchCoordinator con todos los permisos necesarios que requiere el proceso mongot. A partir de MongoDB 8.2, el searchCoordinator es un rol integrado.

Debes realizar las siguientes acciones:

Crea un usuario en el set de réplicas utilizando un recurso personalizado MongoDBUser. El mongot utiliza las credenciales de este usuario para conectarse al set de réplicas y obtener los datos:
- El nombre de usuario es arbitrario (en los ejemplos, usamos search-sync-source-user), pero debe tener el rol searchCoordinator asignado.
- El nombre de usuario y la contraseña de este usuario se pasan en MongoDBSearch.spec.source.username y MongoDBSearch.spec.source.passwordSecretRef respectivamente.
  El secreto de la password puede referirse al mismo secreto que contiene la password del usuario que se utilizó para crear la especificación MongoDBUser (en MongoDBUser.spec.source.passwordSecretKeyRef).
Configura y aplica el recurso personalizado MongoDBSearch.

Para obtener más información sobre la configuración de CR para el proceso mongot, consulta Configuraciones de MongoDB Search y búsqueda vectorial.

mongot implementado en Kubernetes con mongod ejecutándose fuera de Kubernetes

Arquitectura de los procesos mongot desplegados en un clúster de Kubernetes para usar procesos mongod que se ejecutan fuera del clúster de Kubernetes.

El siguiente diagrama muestra la arquitectura de implementación de MongoDB Search y búsqueda vectorial en un clúster de Kubernetes utilizando un set de réplicas externo de la Edición Empresarial de MongoDB.

haga clic para ampliar

El siguiente diagrama muestra los componentes que el operador de Kubernetes implementa en un clúster de Kubernetes para MongoDB Search y búsqueda vectorial.

Diagrama que muestra los componentes incluidos en la implementación del MongoDB Enterprise Replica Set con MongoDB Search usando el operador.

haga clic para ampliar

Para aprovechar MongoDB Search y búsqueda vectorial cuando tienes tu implementación de MongoDB fuera de Kubernetes, implementas mongot utilizando el Operador de Kubernetes y debes realizar algunos pasos manualmente. El Operador de Kubernetes gestiona la configuración de los pods de búsqueda. Sin embargo, cuando el set de réplicas de MongoDB está fuera de Kubernetes, debes reconfigurar tus nodos de MongoDB y la red.

Eres responsable de las siguientes configuraciones manuales:

Configuración externa de MongoDB

Configura el siguiente parámetro usando setParameter en cada proceso mongod en tu set de réplicas externas. Al configurar, sustituye <search-service-hostname>:27027 por el nombre de host y el puerto resolubles reales de tu servicio MongoDBSearch.

setParameter:
  mongotHost: "<search-service-hostname>:27027"
  searchIndexManagementHostAndPort: "<search-service-hostname>:27027"
  skipAuthenticationToSearchIndexManagementServer: false
  searchTLSMode: "disabled"  # or "requireTLS" for TLS deployments

(Sólo para versiones de MongoDB inferiores a (<) 8.2) Crear el searchCoordinator rol personalizado con todos los permisos necesarios.
Desde MongoDB 8.2+, searchCoordinator es un rol incorporado, por lo que puedes omitir este paso.
Crea un usuario en el set de réplicas externo para el proceso de sincronización de búsqueda. Este usuario debe tener el rol searchCoordinator.
```
- userName: "search-sync-source"
  password: "<your-search-sync-password>"
  database: "admin"
  roles:
    - role: "searchCoordinator"
      db: "admin"
```

Configuración de Kubernetes

Configura y aplica el MongoDBSearch CR con spec.source.external apuntando a tus hosts externos de MongoDB.
Crea un secreto de Kubernetes para la contraseña del usuario de sincronización de búsqueda.
```
apiVersion: v1
kind: Secret
metadata:
  name: search-sync-source-password
stringData:
  password: "your-search-sync-password"
```
Cree un secreto de archivo clave que contenga las mismas claves especificadas en el archivo clave utilizado por su set de réplicas externas de MongoDB.
Configure la red y DNS para garantizar la conectividad bidireccional entre su MongoDB externo y los pods de búsqueda. Tu entorno externo de MongoDB debe poder resolver el nombre de host de tu servicio de búsqueda (<search-service-hostname>).

Para obtener más información sobre los ajustes de CR del proceso mongot para conectarse a un proceso mongod externo, consulte Configuración de MongoDB Search and búsqueda vectorial.

Seguridad

La siguiente imagen ilustra la configuración de seguridad del proceso mongot. Si el servidor de MongoDB está dentro del clúster de Kubernetes, el operador de Kubernetes configura automáticamente la autenticación con archivo de claves para MongoDB Search y búsqueda vectorial. Si el servidor MongoDB es externo, se debe crear un secreto de Kubernetes que contenga la credencial keyfile del set de réplicas y hacer referencia a este en el MongoDBSearch CR.

haga clic para ampliar

Autenticación

Al conectarse a mongod, mongot se autentica como un usuario de base de datos. Al implementar MongoDB Search y búsqueda vectorial, debe crear el usuario de base de datos. Debes pasar las credenciales de usuario almacenadas en un secreto de Kubernetes a mongot rellenando los campos spec.source.username y spec.source.passwordSecretRef en el MongoDBSearch CR.

Al aceptar una conexión de mongod, el mongot autentica la solicitud remota utilizando la autenticación interna con keyfiles, similar a la autenticación interna de set de réplicas de MongoDB. Cuando se configura para indexar un recurso de MongoDB en el mismo clúster de Kubernetes, el Operador de Kubernetes configura automáticamente la autenticación de keyfile para MongoDBSearch. Si el set de réplicas de MongoDB se implementa fuera de Kubernetes, debes crear un secreto de Kubernetes que contenga la credencial de keyfile del set de réplicas y referenciarlo en el campo MongoDBSearch.spec.source.external.keyfileSecretRef.

Seguridad de capa de transporte (TLS)

MongoDBSearch puede proteger los datos y las credenciales en tránsito utilizando TLS. Para los comandos de gestión de índices y consultas de búsqueda, especifica (incluso un objeto vacío, {}) el campo spec.security.tls y proporciona un certificado TLS en un secreto de Kubernetes en el campo spec.security.tls.certificateKeySecretRef. Este certificado TLS debe ser emitido y firmado por la misma CA que emitió el certificado CA que utiliza el set de réplicas de MongoDB.

Cuando el Operador de Kubernetes implementa tanto MongoDBSearch como MongoDB, la configuración subyacente de mongot y mongod es manejada en gran medida por el propio Operador de Kubernetes. Cuando el conjunto de réplicas de MongoDB se implementa fuera de Kubernetes, el campo .spec.source.external.tls debe completarse con un secreto de Kubernetes que contenga el mismo certificado CA con el que está configurado mongod, y la propia configuración de mongod debe tener el parámetro searchTLSMode establecido en requireTLS.