Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Caratteristiche e limiti della ricerca vettoriale
Disponibilità della ricerca vettoriale
La ricerca vettoriale per Amazon ElastiCache è disponibile con Valkey versione 8.2 su cluster basati su nodi in tutte le AWS regioni senza costi aggiuntivi. Puoi anche utilizzare la ricerca vettoriale sui cluster esistenti eseguendo l'aggiornamento da qualsiasi versione di Valkey o Redis OSS a Valkey 8.2, in pochi clic e senza tempi di inattività.
La ricerca vettoriale è attualmente disponibile su tutti i tipi di istanze diversi dai nodi con suddivisione in più livelli dei dati. ElastiCache L'utilizzo della ricerca vettoriale su istanze t2, t3 e t4g richiede l'aumento della riserva di memoria ad almeno il 50% per le istanze micro e al 30% per le istanze di piccole dimensioni. Consulta questa pagina per saperne di più.
Restrizioni parametriche
La tabella seguente mostra i limiti per vari elementi di ricerca vettoriale:
| Elemento | Valore massimo |
|---|---|
| Numero di dimensioni in un vettore | 32768 |
| Numero di indici che possono essere creati | 10 |
| Numero di campi in un indice | 50 |
| Clausola FT.SEARCH TIMEOUT (millisecondi) | 60000 |
| Numero massimo di prefissi consentiti per indice | 16 |
| Lunghezza massima di un campo di tag | 10000 |
| Lunghezza massima di un campo numerico | 256 |
| Parametro HNSW M | 2000000 |
| Parametro HNSW EF_CONSTRUCTION | 4096 |
| Parametro HNSW EF_RUNTIME | 4096 |
Restrizioni operative
Persistenza e riempimento dell'indice
Il processo di aggiornamento prevede tre fasi. Nella prima fase, la chiave HASH o JSON viene modificata e il client richiedente viene bloccato. Il secondo passaggio viene eseguito in background e aggiorna ciascuno degli indici che contengono la chiave modificata. Nella terza fase, il client viene sbloccato. Pertanto, per le operazioni di interrogazione eseguite sulla stessa connessione di una mutazione, tale modifica è immediatamente visibile nei risultati della ricerca. Tuttavia, l'inserimento o l'aggiornamento di una chiave potrebbe non essere visibile nei risultati di ricerca di altri client per un breve periodo di tempo. Durante i periodi di intenso carico di sistema ( and/or forte mutazione dei dati), il ritardo di visibilità può aumentare.
La funzione di ricerca vettoriale mantiene la definizione degli indici e il contenuto degli indici. Gli indici per i campi vettoriali vengono salvati ma gli indici per TAGS e NUMERIC non vengono salvati, il che significa che devono essere ricostruiti quando vengono caricati esternamente (sincronizzazione completa o ricarica). Ciò significa che durante qualsiasi richiesta o evento operativo che causa l'avvio o il riavvio di un nodo, la definizione dell'indice e il contenuto dei vettori vengono ripristinati dall'istantanea più recente. Non è richiesta alcuna azione da parte dell'utente per avviare questa operazione. Tuttavia, per gli indici TAGS e NUMERIC, la ricostruzione viene eseguita come operazione di riempimento non appena i dati vengono ripristinati. Dal punto di vista funzionale, ciò equivale all'esecuzione automatica da parte del sistema di un comando FT.CREATE per ogni indice definito. Si noti che il nodo diventa disponibile per le operazioni dell'applicazione non appena i dati vengono ripristinati, ma probabilmente prima del completamento del riempimento dell'indice, il che significa che le operazioni di riempimento saranno nuovamente visibili alle applicazioni.
Il completamento del riempimento dell'indice non è sincronizzato tra un primario e una replica. Questa mancanza di sincronizzazione può diventare inaspettatamente visibile alle applicazioni, pertanto è consigliabile che le applicazioni verifichino il completamento del backfill sulle repliche primarie e su tutte le repliche prima di iniziare le operazioni di ricerca.
Limiti di scalabilità
Durante gli eventi di scalabilità, l'indice può essere sottoposto a riempimento man mano che i dati vengono migrati. Ciò comporterà una riduzione del richiamo per le query di ricerca.
Istantanea import/export e migrazione in tempo reale
I file RDB di un cluster con indici di ricerca possono essere importati in un altro cluster ElastiCache Valkey con versione 8.2 o successiva. Il nuovo cluster ricostruirà il contenuto dell'indice durante il caricamento del file RDB. Tuttavia, la presenza di indici di ricerca in un file RDB limita la compatibilità di tali dati con le versioni precedenti di Valkey. Il formato degli indici di ricerca definiti dalla funzionalità di ricerca vettoriale è compreso solo da un altro ElastiCache cluster con Valkey versione 8.2 o successiva. Tuttavia, i file RDB che non contengono indici non sono soggetti a restrizioni in questo modo.
Memoria insufficiente durante il riempimento
Analogamente alle operazioni di scrittura di Valkey OSS, un riempimento dell'indice è soggetto a limitazioni. out-of-memory Se la memoria del motore è piena mentre è in corso un riempimento, tutti i backfill vengono messi in pausa. Se la memoria diventa disponibile, il processo di riempimento viene ripreso. È possibile eliminare un indice quando il riempimento è in pausa a causa dell'esaurimento della memoria.
Transazioni
I comandiFT.CREATE,, FT.DROPINDEX FT.ALIASADDFT.ALIASDEL, e FT.ALIASUPDATE non possono essere eseguiti in un contesto transazionale, cioè non all'interno di un MULTI/EXEC blocco o all'interno di uno script LUA o FUNCTION.
