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 configurazione MemoryDB abilitata alla ricerca vettoriale è supportata sui tipi di nodi R6g, R7g e T4g ed è disponibile in tutte le regioni in cui è disponibile MemoryDB. AWS

I cluster esistenti non possono essere modificati per abilitare la ricerca. Tuttavia, i cluster abilitati alla ricerca possono essere creati da istantanee di cluster con la ricerca disattivata.

Restrizioni parametriche

La tabella seguente mostra i limiti per vari elementi di ricerca vettoriale:

Limiti di scalabilità

La ricerca vettoriale per MemoryDB è attualmente limitata a un singolo frammento e la scalatura orizzontale non è supportata. La ricerca vettoriale supporta il ridimensionamento verticale e di replica.

Restrizioni operative

Persistenza e riempimento dell'indice

La funzione di ricerca vettoriale mantiene la definizione degli indici e il contenuto dell'indice. Ciò significa che durante qualsiasi richiesta o evento operativo che causa l'avvio o il riavvio di un nodo, la definizione e il contenuto dell'indice vengono ripristinati dall'istantanea più recente e tutte le transazioni in sospeso vengono riprodotte dal Journal. Non è richiesta alcuna azione da parte dell'utente per avviare questa operazione. La ricostruzione viene eseguita come operazione di riempimento non appena i dati vengono ripristinati. Dal punto di vista funzionale, ciò equivale all'esecuzione automatica di un FT da parte del sistema. CREATEcomando per ogni indice definito. Tieni presente 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 i riempimenti torneranno a essere visibili alle applicazioni, ad esempio, i comandi di ricerca che utilizzano gli indici di riempimento potrebbero essere rifiutati. Per ulteriori informazioni sul backfilling, vedere. Panoramica della ricerca vettoriale

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 sui file primari e su tutte le repliche prima di iniziare le operazioni di ricerca.

Importazione/esportazione di istantanee e Live Migration

La presenza di indici di ricerca in un RDB file limita la trasportabilità compatibile di tali dati. Il formato degli indici vettoriali definiti dalla funzionalità di ricerca vettoriale di MemoryDB è compreso solo da un altro cluster abilitato ai vettori di MemoryDB. Inoltre, RDB i file dei cluster di anteprima possono essere importati dalla versione GA dei cluster MemoryDB, che ricostruirà il contenuto dell'indice durante il caricamento del file. RDB

Tuttavia, RDB i file che non contengono indici non sono soggetti a restrizioni in questo modo. Pertanto i dati all'interno di un cluster di anteprima possono essere esportati in cluster non di anteprima eliminando gli indici prima dell'esportazione.

Consumo di memoria

Il consumo di memoria si basa sul numero di vettori, sul numero di dimensioni, sul valore M e sulla quantità di dati non vettoriali, come i metadati associati al vettore o altri dati memorizzati all'interno dell'istanza.

La memoria totale richiesta è una combinazione dello spazio necessario per i dati vettoriali effettivi e dello spazio richiesto per gli indici vettoriali. Lo spazio richiesto per i dati vettoriali viene calcolato misurando la capacità effettiva richiesta per archiviare i vettori all'interno HASH delle nostre strutture di JSON dati e il sovraccarico nelle lastre di memoria più vicine, per allocazioni di memoria ottimali. Ciascuno degli indici vettoriali utilizza riferimenti ai dati vettoriali memorizzati in queste strutture di dati e utilizza ottimizzazioni efficienti della memoria per rimuovere eventuali copie duplicate dei dati vettoriali nell'indice.

Il numero di vettori dipende da come decidete di rappresentare i dati come vettori. Ad esempio, puoi scegliere di rappresentare un singolo documento in più blocchi, in cui ogni blocco rappresenta un vettore. In alternativa, puoi scegliere di rappresentare l'intero documento come un unico vettore.

Il numero di dimensioni dei vettori dipende dal modello di incorporamento scelto. Ad esempio, se scegli di utilizzare il modello di incorporamento AWS Titan, il numero di dimensioni sarebbe 1536.

Il parametro M rappresenta il numero di link bidirezionali creati per ogni nuovo elemento durante la costruzione dell'indice. Il valore predefinito di MemoryDB è 16; tuttavia, è possibile sovrascriverlo. Un parametro M più alto funziona meglio per requisiti di richiamo ridotti ad alta dimensionalità. and/or high recall requirements while low M parameters work better for low dimensionality and/or Il valore M aumenta il consumo di memoria man mano che l'indice aumenta, aumentando il consumo di memoria.

Nell'esperienza della console, MemoryDB offre un modo semplice per scegliere il tipo di istanza giusto in base alle caratteristiche del carico di lavoro vettoriale dopo aver selezionato Abilita la ricerca vettoriale nelle impostazioni del cluster.

Esempio di carico di lavoro

Un cliente desidera creare un motore di ricerca semantico basato sui propri documenti finanziari interni. Attualmente detengono 1 milione di documenti finanziari suddivisi in 10 vettori per documento utilizzando il modello di incorporamento Titan con 1536 dimensioni e non contengono dati non vettoriali. Il cliente decide di utilizzare il valore predefinito di 16 come parametro M.

Con questi dati, il cliente può fare clic sul pulsante Usa calcolatrice vettoriale all'interno della console per ottenere un tipo di istanza consigliato in base ai relativi parametri:

In questo esempio, la calcolatrice vettoriale cercherà il tipo di nodo MemoryDB r7g più piccolo in grado di contenere la memoria necessaria per archiviare i vettori in base ai parametri forniti. Tieni presente che si tratta di un'approssimazione e dovresti testare il tipo di istanza per assicurarti che soddisfi i tuoi requisiti.

In base al metodo di calcolo sopra riportato e ai parametri del carico di lavoro di esempio, questi dati vettoriali richiederebbero 104,9 GB per archiviare i dati e un singolo indice. In questo caso, il tipo di db.r7g.4xlarge istanza è consigliato in quanto dispone di 105,81 GB di memoria utilizzabile. Il successivo tipo di nodo più piccolo sarebbe troppo piccolo per contenere il carico di lavoro vettoriale.

Poiché ciascuno degli indici vettoriali utilizza riferimenti ai dati vettoriali memorizzati e non crea copie aggiuntive dei dati vettoriali nell'indice vettoriale, gli indici occuperanno anche uno spazio relativamente inferiore. Ciò è molto utile per creare più indici e anche in situazioni in cui parti dei dati vettoriali sono state eliminate e la ricostruzione del HNSW grafico aiuterebbe a creare connessioni tra i nodi ottimali per risultati di ricerca vettoriali di alta qualità.

Memoria insufficiente durante il riempimento

Analogamente alle operazioni di OSS scrittura di Valkey e Redis, un riempimento dell'indice è soggetto a limitazioni. out-of-memory Se la memoria del motore è piena mentre è in corso un riempimento, tutti i riempimenti vengono messi in pausa. Se la memoria diventa disponibile, il processo di riempimento viene ripreso. È anche possibile eliminare e indicizzare 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 EXEC bloccoMULTI/o all'interno di uno script or. LUA FUNCTION