Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Características y límites de la búsqueda vectorial
Disponibilidad de búsqueda vectorial
La búsqueda vectorial para Amazon ElastiCache está disponible con la versión 8.2 de Valkey en clústeres basados en nodos de todas AWS las regiones sin coste adicional. También puede utilizar la búsqueda vectorial en los clústeres existentes actualizándolos desde cualquier versión de Valkey o Redis OSS a Valkey 8.2 con unos pocos clics y sin tiempo de inactividad.
La búsqueda vectorial está disponible actualmente en todos los tipos de ElastiCache instancias, excepto en los nodos con niveles de datos. El uso de la búsqueda vectorial en las instancias t2, t3 y t4g requiere aumentar la reserva de memoria al menos al 50 % para las instancias micro y al 30 % para las instancias pequeñas. Consulte esta página para obtener más información.
Restricciones paramétricas
En la siguiente tabla se muestran los límites de varios elementos de búsqueda vectorial:
| Elemento | Valor máximo |
|---|---|
| Cantidad de dimensiones de un vector | 32768 |
| Cantidad de índices que se pueden crear | 10 |
| Cantidad de campos de un índice | 50 |
| Cláusula FT.SEARCH TIMEOUT (milisegundos) | 60000 |
| Número máximo de prefijos permitido por índice | 16 |
| Longitud máxima de un campo de etiqueta | 10000 |
| Longitud máxima de un campo numérico | 256 |
| Parámetro HNSW M | 2000000 |
| Parámetro HNSW EF_CONSTRUCTION | 4096 |
| Parámetro HNSW EF_RUNTIME | 4096 |
Restricciones operativas
Persistencia y reposición de índices
El proceso de actualización consta de tres pasos. En el primer paso, se modifica la clave HASH o JSON y se bloquea el cliente solicitante. El segundo paso se realiza en segundo plano y actualiza cada uno de los índices que contienen la clave modificada. En el tercer paso, se desbloquea el cliente. Por lo tanto, en el caso de las operaciones de consulta realizadas en la misma conexión que una mutación, ese cambio es visible inmediatamente en los resultados de la búsqueda. Por lo tanto, la inserción o actualización de una clave no será visible en los resultados de búsqueda para otros clientes durante un breve período de tiempo. Durante los períodos de alta carga del sistema and/or y una fuerte mutación de los datos, el retraso en la visibilidad puede prolongarse.
La característica de búsqueda vectorial conserva la definición de los índices y el contenido de los índices. Los índices de los campos vectoriales se guardan, pero los índices de TAGS y NUMERIC no, por lo que deben reconstruirse cuando se cargan externamente (sincronización completa o recarga). Esto significa que, durante cualquier solicitud o evento operativo que provoque el inicio o el reinicio de un nodo, la definición y el contenido del índice para los vectores se restauran a partir de la última instantánea. Para iniciar esta operación no se requiere ninguna acción por parte del usuario. Sin embargo, para los índices TAGS y NUMERIC, la reconstrucción se realiza como una operación de rellenado en cuanto se restauran los datos. Esto equivale funcionalmente a que el sistema ejecute automáticamente un comando FT.CREATE para cada índice definido. Tenga en cuenta que el nodo estará disponible para las operaciones de la aplicación tan pronto como se restauren los datos, pero probablemente antes de que se complete el rellenado del índice, lo que significa que las operaciones de rellenado volverán a estar visibles para las aplicaciones.
La finalización de la reposición del índice no se sincroniza entre una reposición principal y una réplica. Esta falta de sincronización puede pasar a ser visible para las aplicaciones de forma inesperada, por lo que se recomienda que las aplicaciones verifiquen que esté finalizada el relleno en las principales y todas las réplicas antes de iniciar las operaciones de búsqueda.
Límites de escalado
Durante los eventos de escalado, es posible que el índice se rellene a medida que se migran los datos. Esto se traduce en una menor recuperación de las consultas de búsqueda.
Migración instantánea import/export y en vivo
Los archivos RDB de un clúster con índices de búsqueda se pueden importar a otro clúster de ElastiCache Valkey con la versión 8.2 o superior. El nuevo clúster reconstruirá el contenido del índice al cargar el archivo RDB. Sin embargo, la presencia de índices de búsqueda en un archivo RDB limita la compatibilidad de esos datos con las versiones anteriores de Valkey. El formato de los índices de búsqueda definido por la funcionalidad de búsqueda vectorial solo lo entiende otro ElastiCache clúster con Valkey en la versión 8.2 o superior. Sin embargo, los archivos RDB que no contienen índices no están restringidos de esta manera.
Falta de memoria durante la reposición
Al igual que las operaciones de escritura del OSS de Valkey, el relleno de índices está sujeto a limitaciones. out-of-memory Si la memoria del motor se llena mientras hay una reposición en curso, todas las reposiciones se pausan. Si queda memoria disponible, se reanuda el proceso de reposición. También se puede eliminar un índice cuando el relleno está en pausa por falta de memoria.
Transacciones
Los comandos FT.CREATE, FT.DROPINDEX, FT.ALIASADD, FT.ALIASDEL y FT.ALIASUPDATE no se pueden ejecutar en un contexto transaccional, es decir, no dentro de un bloque MULTI/EXEC ni dentro de un script LUA o FUNCTION.
