

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.

# Funciones y límites de búsqueda
<a name="search-features-limits"></a>

## Disponibilidad de búsqueda
<a name="search-availability"></a>

ElastiCache La versión 9.0 y las versiones posteriores de Valkey admiten cargas de trabajo exclusivamente no vectoriales, vectoriales e híbridas, incluidas las búsquedas numéricas, de etiquetas (coincidencia exacta) y vectoriales y las agregaciones en clústeres basados en nodos de todas las regiones, sin coste adicional. Full-text AWS 

ElastiCache La versión 8.2 de Valkey admite la búsqueda vectorial en clústeres basados en nodos de todas las regiones sin coste adicional. AWS 

[También puedes utilizar la búsqueda en tus clústeres existentes actualizándolos desde cualquier versión de Valkey o de Redis OSS a las versiones de Valkey mencionadas anteriormente, con unos pocos clics y sin tiempo de inactividad.](VersionManagement.HowTo.md)

Actualmente, la búsqueda está disponible en todos los tipos de ElastiCache instancias, excepto en los nodos con niveles de datos. El uso de la búsqueda 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](redis-memory-management.md) para obtener más información.

## Restricciones paramétricas
<a name="parametric-restrictions"></a>

En la siguiente tabla se muestran los límites de varios elementos de búsqueda:


**Límites de búsqueda**  

| Elemento | Valor máximo (9.0\+) | Valor máximo (8,2) | 
| --- | --- | --- | 
| Cantidad de dimensiones de un vector | 32768 | 32768 | 
| Cantidad de índices que se pueden crear | 1 000 | 10 | 
| Cantidad de campos de un índice | 1 000 | 50 | 
| FT.SEARCH Cláusula TIMEOUT (milisegundos) | 60000 | 60000 | 
| Número máximo de prefijos permitido por índice | 16 | 16 | 
| Longitud máxima de un campo de etiqueta | 10000 | 10000 | 
| Longitud máxima de un campo numérico | 256 | 256 | 
| Parámetro HNSW M | 2000000 | 2000000 | 
| Parámetro HNSW EF\_CONSTRUCTION | 1000000 | 4096 | 
| Parámetro HNSW EF\_RUNTIME | 1000000 | 4096 | 
| Número de términos que se pueden usar en una cadena de consulta en FT.SEARCH/FT.AGGREGATE los comandos | 1 000 | 16 | 
| Número de atributos de texto permitidos por índice | 64 | N/D | 
| Número máximo de expansiones de palabras de texto en las búsquedas de prefijos, sufijos, difusos y términos derivados | 200 | N/D | 

## Restricciones operativas
<a name="operational-restrictions"></a>

### Persistencia y reposición de índices
<a name="index-persistence-backfilling"></a>

Puede obtener más información sobre esto en la sección Creación y relleno del índice de [búsqueda de Valkey](https://valkey.io/topics/search/#index-creation-and-backfill).

### Límites de escalado
<a name="scaling-limits"></a>

En la versión 9.0 de ElastiCache Valkey, durante los eventos de escalado, es posible que el RPS de escritura se reduzca mientras dure el evento. En la versión 8.2 de ElastiCache Valkey, durante los eventos de escalado, el índice puede rellenarse a medida que se migran los datos, lo que reduce la capacidad de recuperación de las consultas de búsqueda.

### Migración instantánea import/export y en tiempo real
<a name="snapshot-import-export"></a>

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
<a name="out-of-memory-backfill"></a>

Al igual que en las operaciones de escritura de Valkey OSS, el relleno de índices está sujeto a limitaciones por falta de memoria. 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
<a name="transactions"></a>

Los comandos `FT.CREATE` y`FT.DROPINDEX`, no se pueden ejecutar en un contexto transaccional, es decir, no dentro de un `MULTI/EXEC` bloque o dentro de un script LUA o FUNCTION. Además, los `FT.AGGREGATE` comandos `FT.SEARCH` y no se pueden ejecutar en un contexto transaccional en un clúster de ElastiCache Valkey que funcione en modo clúster.

## Seguridad de búsquedas
<a name="search-security"></a>

Los mecanismos de seguridad de [ACL (listas de control de acceso) de Valkey](https://valkey.io/topics/acl/) para el acceso a los comandos y a los datos se han ampliado para controlar la función de búsqueda. El control ACL de los comandos de búsqueda individuales es totalmente compatible. Se proporciona una nueva categoría de ACL, `@search`, y muchas de las categorías existentes (`@fast`, `@read`, `@write`, etc.) se actualizan para incluir los nuevos comandos. Los comandos de búsqueda no modifican los datos clave, lo que significa que se conserva la maquinaria ACL existente para el acceso de escritura. La presencia de un índice no modifica las reglas de acceso para las operaciones `HASH` y `JSON`; se sigue aplicando el control de acceso normal en la clave a estos comandos.

El acceso de los comandos de búsqueda con un índice también se controla mediante la ACL. Las comprobaciones de acceso se realizan a nivel de índice completo, no al nivel de la clave. Esto significa que el acceso a un índice se garantiza a un usuario solo si ese usuario tiene permiso para acceder a todas las claves posibles de la lista de prefijos del espacio de claves de ese índice. En otras palabras, el contenido real de un índice no controla el acceso. Más bien, es el contenido teórico de un índice, tal como se define en la lista de prefijos, el que se utiliza para el control de seguridad. Es posible que se produzcan situaciones en las que un usuario tenga acceso de lectura y and/or escritura a una clave, pero no pueda acceder a un índice que contiene esa clave. Tenga en cuenta que solo se requiere acceso de lectura al espacio de claves para crear o usar un índice; no se tiene en cuenta la presencia o ausencia del acceso de escritura.