Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Fonctionnalités et limites de recherche
Rechercher la disponibilité
ElastiCache Les versions 9.0 et supérieures de Valkey prennent en charge les charges de travail purement non vectorielles, vectorielles et hybrides, y compris les recherches numériques, de balises (correspondance exacte) Full-text, vectorielles et les agrégations sur des clusters basés sur des nœuds dans toutes les régions, sans frais supplémentaires. AWS
ElastiCache La version 8.2 de Valkey prend en charge la recherche vectorielle sur des clusters basés sur des nœuds dans toutes les AWS régions sans frais supplémentaires.
Vous pouvez également utiliser la recherche sur vos clusters existants en passant de n'importe quelle version de Valkey, ou de Redis OSS, aux versions de Valkey mentionnées ci-dessus, en quelques clics sans interruption de service.
La recherche est actuellement disponible sur tous les types d' ElastiCache instances autres que les nœuds avec hiérarchisation des données. L'utilisation de la recherche sur les instances t2, t3 et t4g nécessite d'augmenter la réserve de mémoire à au moins 50 % pour les microinstances et à 30 % pour les petites instances. Consultez cette page pour en savoir plus.
Restrictions paramétriques
Le tableau suivant indique les limites des différents éléments de recherche :
| Élément | Valeur maximale (9,0+) | Valeur maximale (8,2) |
|---|---|---|
| Nombre de dimensions dans un vecteur | 32768 | 32768 |
| Nombre d'index pouvant être créés | 1 000 | 10 |
| Nombre de champs dans un index | 1 000 | 50 |
| FT.SEARCH Clause TIMEOUT (millisecondes) | 60000 | 60000 |
| Nombre maximum de préfixes autorisés par index | 16 | 16 |
| Longueur maximale d'un champ de tag | 10 000 | 10 000 |
| Longueur maximale d'un champ numérique | 256 | 256 |
| Paramètre HNSW M | 2000000 | 2000000 |
| Paramètre HNSW EF_CONSTRUCTION | 1000000 | 4096 |
| Paramètre HNSW EF_RUNTIME | 1000000 | 4096 |
| Nombre de termes autorisés à être utilisés dans une chaîne de requête dans FT.SEARCH/FT.AGGREGATE les commandes | 1 000 | 16 |
| Nombre d'attributs de texte autorisés par index | 64 | NA |
| Expansion maximale des mots de texte dans les recherches par préfixe, suffixe, flou et radical | 200 | NA |
Restrictions opérationnelles
Persistance de l'indice et remblayage
Vous pouvez en savoir plus à ce sujet sur Création et remplissage de l'index de recherche Valkey.
Limites d'échelle
Dans la version 9.0 de ElastiCache Valkey, lors des événements de dimensionnement, le RPS d'écriture peut être réduit pendant la durée de l'événement. Dans la version 8.2 de ElastiCache Valkey, lors d'événements de dimensionnement, l'index peut être remplacé lors de la migration des données, ce qui réduira le nombre de rappels pour les requêtes de recherche.
Instantané import/export et migration en direct
Les fichiers RDB d'un cluster avec des index de recherche peuvent être importés vers un autre cluster ElastiCache Valkey avec la version 8.2 ou supérieure. Le nouveau cluster reconstruira le contenu de l'index lors du chargement du fichier RDB. Cependant, la présence d'index de recherche dans un fichier RDB limite la compatibilité de ces données avec les versions antérieures de Valkey. Le format des index de recherche défini par la fonctionnalité de recherche vectorielle n'est compris que par un autre ElastiCache cluster doté de la version 8.2 ou supérieure de Valkey. Cependant, les fichiers RDB qui ne contiennent pas d'index ne sont pas restreints de cette manière.
Mémoire insuffisante pendant le remblayage
À l'instar des opérations d'écriture de Valkey OSS, le remplissage d'un index est soumis à des limites de mémoire insuffisante. Si la mémoire du moteur est pleine alors qu'un remblayage est en cours, tous les remplissages sont interrompus. Si de la mémoire devient disponible, le processus de remplissage reprend. Il est possible de supprimer un index lorsque le remplissage est suspendu en raison d'un manque de mémoire.
Transactions
Les commandes FT.CREATE etFT.DROPINDEX, ne peuvent pas être exécutées dans un contexte transactionnel, c'est-à-dire pas dans un MULTI/EXEC bloc ou dans un script LUA ou FUNCTION. De plus, les FT.AGGREGATE commandes FT.SEARCH et ne peuvent pas être exécutées dans un contexte transactionnel dans un cluster ElastiCache Valkey fonctionnant en mode cluster.
Sécurité des recherches
Les mécanismes de sécurité Valkey ACL (Access Control Lists)@search,, est fournie et de nombreuses catégories existantes (@fast,, @read@write, etc.) sont mises à jour pour inclure les nouvelles commandes. Les commandes de recherche ne modifient pas les données clés, ce qui signifie que le mécanisme ACL existant pour l'accès en écriture est préservé. Les règles d'accès HASH et les JSON opérations ne sont pas modifiées par la présence d'un index ; le contrôle d'accès normal au niveau des clés est toujours appliqué à ces commandes.
L'accès aux commandes de recherche avec index est également contrôlé via ACL. Les contrôles d'accès sont effectués au niveau de l'index complet, et non au niveau de chaque clé. Cela signifie que l'accès à un index n'est accordé à un utilisateur que s'il est autorisé à accéder à toutes les clés possibles dans la liste des préfixes d'espace-touches de cet index. En d'autres termes, le contenu réel d'un index ne contrôle pas l'accès. C'est plutôt le contenu théorique d'un index tel que défini par la liste de préfixes qui est utilisé pour le contrôle de sécurité. Il est possible qu'un utilisateur dispose d'un accès en lecture et en and/or écriture à une clé mais ne puisse pas accéder à un index contenant cette clé. Notez que seul l'accès en lecture au keyspace est requis pour créer ou utiliser un index ; la présence ou l'absence d'accès en écriture n'est pas prise en compte.
