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.
Caractéristiques et limites de la recherche vectorielle
Disponibilité de la recherche vectorielle
La recherche vectorielle pour Amazon ElastiCache est disponible avec la version 8.2 de Valkey sur les clusters basés sur des nœuds dans toutes les AWS régions, sans frais supplémentaires. Vous pouvez également utiliser la recherche vectorielle sur vos clusters existants en passant de n'importe quelle version de Valkey, ou de Redis OSS, à Valkey 8.2, en quelques clics, sans interruption de service.
La recherche vectorielle 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 vectorielle 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 applicables aux différents éléments de recherche vectorielle :
| Élément | Valeur maximale |
|---|---|
| Nombre de dimensions dans un vecteur | 32768 |
| Nombre d'index pouvant être créés | 10 |
| Nombre de champs dans un index | 50 |
| Clause FT.SEARCH TIMEOUT (millisecondes) | 60000 |
| Nombre maximum de préfixes autorisés par index | 16 |
| Longueur maximale d'un champ de tag | 10 000 |
| Longueur maximale d'un champ numérique | 256 |
| Paramètre HNSW M | 2000000 |
| Paramètre HNSW EF_CONSTRUCTION | 4096 |
| Paramètre HNSW EF_RUNTIME | 4096 |
Restrictions opérationnelles
Persistance de l'indice et remblayage
Le processus de mise à jour comporte trois étapes. Dans un premier temps, la clé HASH ou JSON est modifiée et le client demandeur est bloqué. La deuxième étape est exécutée en arrière-plan et met à jour chacun des index contenant la clé modifiée. Dans la troisième étape, le client est débloqué. Ainsi, pour les opérations de requête effectuées sur la même connexion qu'une mutation, cette modification est immédiatement visible dans les résultats de recherche. Cependant, il est possible que l'insertion ou la mise à jour d'une clé ne soit pas visible dans les résultats de recherche d'autres clients pendant une courte période. Pendant les périodes de forte charge du système et de and/or forte mutation des données, le délai de visibilité peut s'allonger.
La fonction de recherche vectorielle conserve la définition des index et le contenu des index. Les index des champs vectoriels sont enregistrés mais ceux des champs TAGS et NUMERIC ne le sont pas, ce qui signifie qu'ils doivent être reconstruits lorsqu'ils sont chargés en externe (synchronisation complète ou rechargement). Cela signifie que lors de toute demande ou événement opérationnel entraînant le démarrage ou le redémarrage d'un nœud, la définition de l'index et le contenu des vecteurs sont restaurés à partir du dernier instantané. Aucune action de l'utilisateur n'est requise pour lancer cette opération. Toutefois, pour les index TAGS et NUMERIC, la reconstruction est effectuée en tant qu'opération de remblayage dès que les données sont restaurées. Cela équivaut fonctionnellement à l'exécution automatique par le système d'une commande FT.CREATE pour chaque index défini. Notez que le nœud devient disponible pour les opérations d'application dès que les données sont restaurées, mais probablement avant la fin du remplissage de l'index, ce qui signifie que les opérations de remplissage redeviendront visibles pour les applications.
L'achèvement du remplissage de l'index n'est pas synchronisé entre un index principal et un réplica. Ce manque de synchronisation peut devenir visible de manière inattendue pour les applications. Il est donc recommandé aux applications de vérifier que le remblayage est terminé sur les primaires et sur toutes les répliques avant de lancer des opérations de recherche.
Limites d'échelle
Lors des événements de dimensionnement, l'index peut être remplacé au fur et à mesure que les données sont migrées. Cela 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. Toutefois, 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'index est soumis à out-of-memory des limitations. 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 remblayage est repris. Il est possible de supprimer un index lorsque le remplissage est suspendu en raison d'un manque de mémoire.
Transactions
Les commandesFT.CREATE,FT.DROPINDEX, FT.ALIASADDFT.ALIASDEL, et FT.ALIASUPDATE 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.
