Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Funktionen und Grenzen der Vektorsuche

Verfügbarkeit der Vektorsuche

Die MemoryDB-Konfiguration mit aktivierter Vektorsuche wird auf den Knotentypen R6g, R7g und T4g unterstützt und ist in allen Regionen verfügbar, in denen MemoryDB verfügbar ist. AWS

Bestehende Cluster können nicht geändert werden, um die Suche zu ermöglichen. Cluster mit aktivierter Suche können jedoch aus Snapshots von Clustern mit deaktivierter Suche erstellt werden.

Parametrische Einschränkungen

Die folgende Tabelle zeigt Grenzwerte für verschiedene Vektor-Suchelemente:

Skalierungsgrenzen

Die Vektorsuche für MemoryDB ist derzeit auf einen einzelnen Shard beschränkt und die horizontale Skalierung wird nicht unterstützt. Die Vektorsuche unterstützt die vertikale Skalierung und die Skalierung von Replikaten.

Betriebliche Einschränkungen

Persistenz und Backfilling von Indizes

Die Vektorsuchfunktion speichert die Definition von Indizes und den Inhalt des Indexes. Das bedeutet, dass bei jeder Betriebsanfrage oder bei jedem Ereignis, das den Start oder Neustart eines Knotens veranlasst, die Indexdefinition und der Inhalt aus dem letzten Snapshot wiederhergestellt werden und alle ausstehenden Transaktionen aus dem Journal wiedergegeben werden. Um dies zu initiieren, ist keine Benutzeraktion erforderlich. Die Wiederherstellung wird als Backfill-Vorgang ausgeführt, sobald die Daten wiederhergestellt sind. Dies entspricht funktionell der automatischen Ausführung einer FT-Datei durch das System. CREATEBefehl für jeden definierten Index. Beachten Sie, dass der Knoten für Anwendungsoperationen verfügbar ist, sobald die Daten wiederhergestellt sind, aber wahrscheinlich, bevor das Auffüllen des Index abgeschlossen ist. Das bedeutet, dass Backfill (s) wieder für Anwendungen sichtbar werden. Beispielsweise können Suchbefehle, die Backfill-Indizes verwenden, zurückgewiesen werden. Weitere Informationen zum Backfilling finden Sie unter. Überblick über die Vektorsuche

Der Abschluss des Index-Backfills wird nicht zwischen einem Primär- und einem Replikat synchronisiert. Dieser Mangel an Synchronisation kann für Anwendungen unerwartet sichtbar werden. Daher wird empfohlen, dass Anwendungen den Abschluss des Backfill-Vorgangs für Primärdateien und alle Replikate überprüfen, bevor sie Suchvorgänge einleiten.

Import/Export von Snapshots und Live-Migration

Das Vorhandensein von Suchindizes in einer RDB Datei schränkt die kompatible Übertragbarkeit dieser Daten ein. Das Format der Vektorindizes, das durch die MemoryDB-Vektorsuchfunktion definiert wird, wird nur von einem anderen MemoryDB-Vektor-Cluster verstanden. Außerdem können die RDB Dateien aus den Vorschauclustern mit der GA-Version der MemoryDB-Cluster importiert werden, wodurch der Indexinhalt beim Laden der Datei neu erstellt wird. RDB

RDBDateien, die keine Indizes enthalten, sind auf diese Weise jedoch nicht eingeschränkt. Somit können Daten innerhalb eines Vorschau-Clusters in Cluster exportiert werden, die keine Vorschau-Cluster sind, indem die Indizes vor dem Export gelöscht werden.

Speicherverbrauch

Der Speicherverbrauch basiert auf der Anzahl der Vektoren, der Anzahl der Dimensionen, dem M-Wert und der Menge der Nicht-Vektordaten, z. B. Metadaten, die dem Vektor zugeordnet sind, oder auf anderen in der Instanz gespeicherten Daten.

Der Gesamtspeicherbedarf ist eine Kombination aus dem für die eigentlichen Vektordaten benötigten Speicherplatz und dem für die Vektorindizes benötigten Speicherplatz. Der für Vektordaten benötigte Speicherplatz wird berechnet, indem die tatsächliche Kapazität gemessen wird, die für die Speicherung von Vektoren in unseren HASH JSON Datenstrukturen erforderlich ist, und der Overhead bis zu den nächstgelegenen Speicherplatten, um optimale Speicherzuweisungen zu erzielen. Jeder der Vektorindizes verwendet Verweise auf die in diesen Datenstrukturen gespeicherten Vektordaten und verwendet effiziente Speicheroptimierungen, um alle doppelten Kopien der Vektordaten im Index zu entfernen.

Die Anzahl der Vektoren hängt davon ab, wie Sie Ihre Daten als Vektoren darstellen möchten. Sie können beispielsweise festlegen, dass ein einzelnes Dokument in mehreren Abschnitten dargestellt wird, wobei jeder Abschnitt einen Vektor darstellt. Sie können sich auch dafür entscheiden, das gesamte Dokument als einen einzigen Vektor darzustellen.

Die Anzahl der Dimensionen Ihrer Vektoren hängt vom ausgewählten Einbettungsmodell ab. Wenn Sie sich beispielsweise für das AWS Titan-Einbettungsmodell entscheiden, beträgt die Anzahl der Dimensionen 1536.

Der Parameter M steht für die Anzahl der bidirektionalen Links, die bei der Indexerstellung für jedes neue Element erstellt werden. MemoryDB setzt diesen Wert standardmäßig auf 16; Sie können ihn jedoch überschreiben. Ein höherer M-Parameter eignet sich besser für hohe Dimensionalität and/or high recall requirements while low M parameters work better for low dimensionality and/or und geringe Erinnerungsanforderungen. Der M-Wert erhöht den Speicherverbrauch, wenn der Index größer wird, was den Speicherverbrauch erhöht.

In der Konsolenumgebung bietet MemoryDB eine einfache Möglichkeit, den richtigen Instance-Typ auf der Grundlage der Eigenschaften Ihres Vektor-Workloads auszuwählen, nachdem Sie in den Cluster-Einstellungen die Option Vektorsuche aktivieren aktiviert haben.

Beispiel für eine Arbeitslast

Ein Kunde möchte eine semantische Suchmaschine aufbauen, die auf seinen internen Finanzdokumenten aufbaut. Sie verfügen derzeit über 1 Million Finanzdokumente, die mithilfe des Titan-Einbettungsmodells mit 1536 Dimensionen in 10 Vektoren pro Dokument aufgeteilt sind und keine Daten enthalten, die keine Vektordaten enthalten. Der Kunde entscheidet sich dafür, den Standardwert 16 als M-Parameter zu verwenden.

Mit diesen Daten kann der Kunde in der Konsole auf die Schaltfläche Vektorrechner verwenden klicken, um anhand seiner Parameter einen empfohlenen Instanztyp zu erhalten:

In diesem Beispiel sucht der Vektorrechner anhand der angegebenen Parameter nach dem kleinsten MemoryDB-R7G-Knotentyp, der den zum Speichern der Vektoren erforderlichen Speicher aufnehmen kann. Beachten Sie, dass dies eine Näherung ist und Sie den Instance-Typ testen sollten, um sicherzustellen, dass er Ihren Anforderungen entspricht.

Basierend auf der obigen Berechnungsmethode und den Parametern im Beispiel-Workload würden für diese Vektordaten 104,9 GB zum Speichern der Daten und eines einzelnen Index benötigt. In diesem Fall würde der db.r7g.4xlarge Instance-Typ empfohlen, da er über 105,81 GB nutzbaren Speicher verfügt. Der nächstkleinere Knotentyp wäre zu klein, um die Vektor-Arbeitslast aufzunehmen.

Da jeder der Vektorindizes Verweise auf die gespeicherten Vektordaten verwendet und keine zusätzlichen Kopien der Vektordaten im Vektorindex erstellt, verbrauchen die Indizes auch relativ weniger Speicherplatz. Dies ist sehr nützlich bei der Erstellung mehrerer Indizes und auch in Situationen, in denen Teile der Vektordaten gelöscht wurden und die Rekonstruktion des HNSW Graphen dabei helfen würde, optimale Knotenverbindungen für qualitativ hochwertige Vektorsuchergebnisse zu schaffen.

Beim Auffüllen ist nicht genügend Speicherplatz verfügbar

Ähnlich wie bei den OSS Schreiboperationen Valkey und Redis unterliegt auch das Auffüllen von Indizes Einschränkungen. out-of-memory Wenn der Engine-Speicher voll ist, während ein Backfill läuft, werden alle Backfills angehalten. Wenn Speicher verfügbar wird, wird der Backfill-Vorgang wieder aufgenommen. Es ist auch möglich, zu löschen und zu indizieren, wenn das Auffüllen aufgrund von Speichermangel unterbrochen wird.

Transaktionen

Die BefehleFT.CREATE,, FT.DROPINDEX FT.ALIASADDFT.ALIASDEL, und FT.ALIASUPDATE können nicht in einem Transaktionskontext ausgeführt werden, d. h. nicht innerhalb eines MULTI EXEC /-Blocks oder innerhalb eines Or-Skripts. LUA FUNCTION