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. # Vektor-Suche Die Vektorsuche für MemoryDB erweitert die Funktionalität von MemoryDB. Die Vektorsuche kann in Verbindung mit vorhandenen MemoryDB-Funktionen verwendet werden. Anwendungen, die die Vektorsuche nicht verwenden, sind von ihrer Präsenz nicht betroffen. Die Vektorsuche ist in allen Regionen verfügbar, in denen MemoryDB verfügbar ist. Die Vektorsuche für vereinfacht Ihre Anwendungsarchitektur und bietet gleichzeitig eine Hochgeschwindigkeits-Vektorsuche. Die Vektorsuche für MemoryDB ist ideal für Anwendungsfälle, bei denen Spitzenleistung und Skalierbarkeit die wichtigsten Auswahlkriterien sind. Sie können Ihre vorhandenen MemoryDB-Daten oder eine Valkey- oder Redis OSS-API verwenden, um Anwendungsfälle für maschinelles Lernen und generative KI zu erstellen. Dazu gehören die Generierung mit erweitertem Abruf, die Erkennung von Anomalien, das Abrufen von Dokumenten und Empfehlungen in Echtzeit. Seit dem 26.06.2024 bietet AWS MemoryDB die schnellste Vektor-Suchleistung bei den höchsten Abrufraten aller gängigen Vektordatenbanken. AWS **Topics** + [ # Überblick über die Vektorsuche ](vector-search-overview.md) + [ # Anwendungsfälle ](vector-search-examples.md) + [ # Funktionen und Grenzen der Vektorsuche ](vector-search-limits.md) + [ # Erstellen Sie einen Cluster, der für die Vektorsuche aktiviert ist ](vector-search-cluster.md) + [ # Befehle für die Vektorsuche ](vector-search-commands.md) # Überblick über die Vektorsuche Die Vektorsuche basiert auf der Erstellung, Pflege und Verwendung von Indizes. Jede Vektorsuchoperation spezifiziert einen einzelnen Index und ihre Operation ist auf diesen Index beschränkt, d. h. Operationen an einem Index werden von Operationen an einem anderen Index nicht beeinflusst. Mit Ausnahme der Operationen zum Erstellen und Löschen von Indizes können jederzeit beliebig viele Operationen für jeden Index ausgeführt werden, was bedeutet, dass auf Clusterebene mehrere Operationen mit mehreren Indizes gleichzeitig ausgeführt werden können. Einzelne Indizes sind benannte Objekte, die in einem eindeutigen Namespace existieren, der sich von den anderen Valkey- und Redis-OSS-Namespaces unterscheidet: Schlüssel, Funktionen usw. Jeder Index ähnelt konzeptionell einer herkömmlichen Datenbanktabelle, da er in zwei Dimensionen strukturiert ist: Spalten und Zeilen. Jede Zeile in der Tabelle entspricht einem Schlüssel. Jede Spalte im Index entspricht einem Element oder Teil dieses Schlüssels. In diesem Dokument sind die Begriffe Schlüssel, Zeile und Datensatz identisch und werden synonym verwendet. In ähnlicher Weise sind die Begriffe Spalte, Feld, Pfad und Element im Wesentlichen identisch und werden auch synonym verwendet. Es gibt keine speziellen Befehle zum Hinzufügen, Löschen oder Ändern indizierter Daten. Vielmehr aktualisieren die vorhandenen **JSON** Befehle **HASH** oder Befehle, die einen Schlüssel ändern, der sich in einem Index befindet, auch automatisch den Index. **Topics** + [ ## Indizes und der OSS-Schlüsselraum von Valkey und Redis ](#vector-search-indexes-keyspaces) + [ ## Typen von Indexfeldern ](#vector-search-index-field-types) + [ ## Vektor-Index-Algorithmen ](#vector-search-index-algorithms) + [ ## Ausdruck für eine Vektor-Suchanfrage ](#vector-search-query-expression) + [ ## Befehl INFO ](#vector-search-ft.info) + [ ## Sicherheit bei der Vektorsuche ](#vector-search-security) ## Indizes und der OSS-Schlüsselraum von Valkey und Redis Indizes werden über eine Teilmenge des OSS-Schlüsselraums Valkey und Redis erstellt und verwaltet. Bei mehreren Indizes können unzusammenhängende oder überlappende Teilmengen des Schlüsselraums ohne Einschränkung ausgewählt werden. Der Schlüsselraum für jeden Index wird durch eine Liste von Schlüsselpräfixen definiert, die bei der Indexerstellung bereitgestellt werden. Die Liste der Präfixe ist optional, und wenn sie weggelassen wird, ist der gesamte Schlüsselraum Teil dieses Indexes. Indizes werden auch so eingegeben, dass sie nur Schlüssel abdecken, die einen passenden Typ haben. Derzeit werden nur JSON- und HASH-Indizes unterstützt. Ein HASH-Index indexiert nur HASH-Schlüssel, die in seiner Präfixliste enthalten sind, und in ähnlicher Weise indexiert ein JSON-Index nur JSON-Schlüssel, die in seiner Präfixliste enthalten sind. Schlüssel in der Schlüsselraum-Präfixliste eines Indexes, die nicht den angegebenen Typ haben, werden ignoriert und wirken sich nicht auf Suchvorgänge aus. Wenn ein HASH- oder JSON-Befehl einen Schlüssel ändert, der sich innerhalb eines Schlüsselraums eines Indexes befindet, wird dieser Index aktualisiert. Dieser Prozess beinhaltet das Extrahieren der deklarierten Felder für jeden Index und das Aktualisieren des Index mit dem neuen Wert. Der Aktualisierungsprozess wird in einem Hintergrundthread durchgeführt, was bedeutet, dass die Indizes erst irgendwann mit ihren Schlüsselrauminhalten konsistent sind. Somit ist das Einfügen oder Aktualisieren eines Schlüssels für einen kurzen Zeitraum nicht in den Suchergebnissen sichtbar. In Zeiten hoher Systemlast und and/or starker Datenmutation kann die Sichtbarkeitsverzögerung länger werden. Die Erstellung eines Index ist ein mehrstufiger Prozess. Der erste Schritt besteht darin, den Befehl [FT.CREATE](https://docs.aws.amazon.com/memorydb/latest/devguide/vector-search-commands-ft.create.html) auszuführen, der den Index definiert. Bei erfolgreicher Ausführung einer Erstellung wird automatisch der zweite Schritt eingeleitet — das Backfilling. Der Backfill-Prozess läuft in einem Hintergrund-Thread und durchsucht den Schlüsselbereich nach Schlüsseln, die sich in der Präfixliste des neuen Indexes befinden. Jeder gefundene Schlüssel wird dem Index hinzugefügt. Schließlich wird der gesamte Schlüsselraum gescannt, wodurch der Indexerstellungsprozess abgeschlossen ist. Beachten Sie, dass während der Ausführung des Backfill-Prozesses Mutationen von indizierten Schlüsseln zulässig sind, es keine Einschränkungen gibt und der Index-Backfill-Prozess erst abgeschlossen wird, wenn alle Schlüssel ordnungsgemäß indexiert sind. Abfrageoperationen, die versucht werden, während ein Index aufgefüllt wird, sind nicht zulässig und werden mit einem Fehler beendet. Der Abschluss des Backfill-Vorgangs kann anhand der Ausgabe des `FT.INFO` Befehls für diesen Index ('backfill\$1status') ermittelt werden. ## Typen von Indexfeldern Jedes Feld (Spalte) eines Indexes hat einen bestimmten Typ, der bei der Indexerstellung deklariert wird, sowie eine Position innerhalb eines Schlüssels. Bei HASH-Schlüsseln ist der Speicherort der Feldname innerhalb des HASH. Bei JSON-Schlüsseln ist der Speicherort eine JSON-Pfadbeschreibung. Wenn ein Schlüssel geändert wird, werden die mit den deklarierten Feldern verknüpften Daten extrahiert, in den deklarierten Typ konvertiert und im Index gespeichert. Wenn die Daten fehlen oder nicht erfolgreich in den deklarierten Typ konvertiert werden können, wird dieses Feld aus dem Index weggelassen. Es gibt vier Arten von Feldern, die im Folgenden erklärt werden: + **Zahlenfelder** enthalten eine einzelne Zahl. Bei JSON-Feldern müssen die numerischen Regeln für JSON-Nummern befolgt werden. Bei HASH wird erwartet, dass das Feld den ASCII-Text einer Zahl enthält, die im Standardformat für Fest- oder Fließkommazahlen geschrieben ist. Unabhängig von der Darstellung innerhalb des Schlüssels wird dieses Feld zur Speicherung im Index in eine 64-Bit-Fließkommazahl umgewandelt. Zahlenfelder können mit dem Bereichssuchoperator verwendet werden. Da die zugrunde liegenden Zahlen mit ihren Genauigkeitsbeschränkungen in Fließkommazahlen gespeichert werden, gelten die üblichen Regeln für numerische Vergleiche für Fließkommazahlen. + **Tag-Felder** enthalten null oder mehr Tag-Werte, die als einzelne UTF-8-Zeichenfolge codiert sind. Die Zeichenfolge wird mithilfe eines Trennzeichens (Standard ist ein Komma, kann aber überschrieben werden) in Tagwerte zerlegt, wobei führende und nachfolgende Leerzeichen entfernt werden. In einem einzigen Tag-Feld können beliebig viele Tag-Werte enthalten sein. Tag-Felder können verwendet werden, um Abfragen nach der Äquivalenz von Tag-Werten zu filtern, wobei entweder Groß- und Kleinschreibung berücksichtigt wird oder nicht. + **Textfelder** enthalten einen Blob von Bytes, die nicht UTF-8-kompatibel sein müssen. Textfelder können verwendet werden, um Abfrageergebnisse mit anwendungsrelevanten Werten zu versehen. Zum Beispiel eine URL oder der Inhalt eines Dokuments usw. + **Vektorfelder** enthalten einen Zahlenvektor, der auch als Einbettung bezeichnet wird. Vektorfelder unterstützen die Suche nach dem K-Nearest Neighbor (KNN) von Vektoren fester Größe unter Verwendung eines bestimmten Algorithmus und einer bestimmten Entfernungsmetrik. Bei HASH-Indizes sollte das Feld den gesamten Vektor enthalten, der im Binärformat codiert ist (*Little-Endian* IEEE 754). Bei JSON-Schlüsseln sollte der Pfad auf ein mit Zahlen gefülltes Array der richtigen Größe verweisen. Beachten Sie, dass bei der Verwendung eines JSON-Arrays als Vektorfeld die interne Darstellung des Arrays innerhalb des JSON-Schlüssels in das für den ausgewählten Algorithmus erforderliche Format konvertiert wird, wodurch der Speicherverbrauch und die Genauigkeit reduziert werden. Nachfolgende Lesevorgänge mit den JSON-Befehlen ergeben den reduzierten Genauigkeitswert. ## Vektor-Index-Algorithmen Es stehen zwei Vektorindex-Algorithmen zur Verfügung: + **Flach** — Der Flat-Algorithmus ist eine lineare Brute-Force-Verarbeitung aller Vektoren im Index, die exakte Antworten innerhalb der Grenzen der Genauigkeit der Entfernungsberechnungen liefert. Aufgrund der linearen Verarbeitung des Index können die Laufzeiten für diesen Algorithmus bei großen Indizes sehr hoch sein. + **HNSW (Hierarchical Navigable Small Worlds)** — Der HNSW-Algorithmus ist eine Alternative, die im Austausch für wesentlich kürzere Ausführungszeiten eine Annäherung an die richtige Antwort liefert. Der Algorithmus wird durch drei Parameter gesteuert, und. `M` `EF_CONSTRUCTION` `EF_RUNTIME` Die ersten beiden Parameter werden bei der Indexerstellung angegeben und können nicht geändert werden. Der `EF_RUNTIME` Parameter hat einen Standardwert, der bei der Indexerstellung angegeben wird, aber danach bei jedem einzelnen Abfragevorgang überschrieben werden kann. Diese drei Parameter wirken zusammen, um den Speicher- und CPU-Verbrauch bei Aufnahme- und Abfragevorgängen auszugleichen und die Qualität der Annäherung an eine exakte KNN-Suche (bekannt als Recall-Ratio) zu steuern. Beide Vektorsuchalgorithmen (Flat und HNSW) unterstützen einen optionalen Parameter. `INITIAL_CAP` Wenn dieser Parameter angegeben ist, weist er den Indizes vorab Speicher zu, was zu einem geringeren Speicherverwaltungsaufwand und höheren Vektoraufnahmeraten führt. Vektorsuchalgorithmen wie HNSW können das Löschen oder Überschreiben zuvor eingefügter Vektoren möglicherweise nicht effizient handhaben. Die Verwendung dieser Operationen kann zu einem übermäßigen Index-Speicherverbrauch und einer and/or Verschlechterung der Abrufqualität führen. Die Neuindizierung ist eine Methode zur Wiederherstellung einer optimalen Speicherauslastung beim Abrufen. and/or ## Ausdruck für eine Vektor-Suchanfrage Die Befehle [FT.SEARCH](https://docs.aws.amazon.com/memorydb/latest/devguide/vector-search-commands-ft.search.html) und [FT.AGGREGATE](https://docs.aws.amazon.com/memorydb/latest/devguide/vector-search-commands-ft.aggregate.html) erfordern einen Abfrageausdruck. Dieser Ausdruck ist ein einzelner Zeichenkettenparameter, der aus einem oder mehreren Operatoren besteht. Jeder Operator verwendet ein Feld im Index, um eine Teilmenge der Schlüssel im Index zu identifizieren. Mehrere Operatoren können mithilfe von booleschen Kombinatoren sowie Klammern kombiniert werden, um den gesammelten Satz von Schlüsseln (oder die Ergebnismenge) weiter zu erweitern oder einzuschränken. ### Platzhalter Der Platzhalteroperator, das Sternchen ('\$1'), entspricht allen Schlüsseln im Index. ### Numerischer Bereich Der numerische Bereichsoperator hat die folgende Syntax: ``` ::= '@' ':' '[' ']' ::= | '(' ::= | | | 'Inf' | '-Inf' | '+Inf' ``` Bei < numeric-field-name > muss es sich um ein deklariertes Feld vom Typ handeln`NUMERIC`. Standardmäßig ist die Grenze inklusiv, aber eine führende offene Klammer ['('] kann verwendet werden, um eine Grenze exklusiv zu machen. Die Bereichssuche kann mithilfe `Inf` von `+Inf` oder `-Inf` als eine der Grenzen in einen einzelnen relationalen Vergleich (<, <=, >, > =) umgewandelt werden. Unabhängig vom angegebenen numerischen Format (Ganzzahl, Festkomma, Gleitkomma, Unendlich) wird die Zahl für Vergleiche in 64-Bit-Gleitkommazahlen umgewandelt, wodurch die Genauigkeit entsprechend reduziert wird. **Example Beispiele** ``` @numeric-field:[0 10] // 0 <= <= 10 @numeric-field:[(0 10] // 0 < <= 10 @numeric-field:[0 (10] // 0 <= < 10 @numeric-field:[(0 (10] // 0 < < 10 @numeric-field:[1.5 (Inf] // 1.5 <= value ``` ### Tag-Vergleich Der Tag-Vergleichsoperator hat die folgende Syntax: ``` ::= '@' ':' '{' [ '|' ]* '}' ``` Wenn eines der Tags im Operator mit einem der Tags im Tag-Feld des Datensatzes übereinstimmt, wird der Datensatz in die Ergebnismenge aufgenommen. Das von dem entworfene Feld `` muss ein Feld des mit type deklarierten Index sein. `TAG` Beispiele für einen Tag-Vergleich sind: ``` @tag-field:{ atag } @tag-field: { tag1 | tag2 } ``` ### Boolesche Kombinationen Die Ergebnismengen eines numerischen Operators oder eines Tag-Operators können mithilfe einer booleschen Logik kombiniert werden: and/or. Parentheses can be used to group operators and/or Ändern Sie die Reihenfolge der Auswertung. Die Syntax boolescher Logikoperatoren lautet: ``` ::= | '|' | '(' ')' ::= | ::= | | '*' ``` Mehrere Begriffe, die zu einer Phrase zusammengefasst sind, sind „und“ -ed. Mehrere Phrasen, die mit einem senkrechten Strich ('\$1') kombiniert werden, stehen für „oder“. ### Vektor-Suche Vektorindizes unterstützen zwei verschiedene Suchmethoden: Nearest Neighbor und Range. Bei der Suche nach dem nächsten Nachbarn wird eine Zahl, K, der Vektoren im Index gefunden, die dem angegebenen (Referenz-) Vektor am nächsten sind. Dies wird umgangssprachlich KNN für „K“ -Nearest Neighbours genannt. Die Syntax für eine KNN-Suche lautet: ``` ::= '=>[KNN' '@' '$' ']' ::= [ 'EF_RUNTIME' ] [ 'AS' ] ``` Eine Vektor-KNN-Suche wird nur auf die Vektoren angewendet, die die Kriterien erfüllen. Dabei kann es sich um eine beliebige Kombination der oben definierten Operatoren handeln: Platzhalter, Bereichssuche, Tagsuche, and/or boolesche Kombinationen `` davon. + ``ist eine Ganzzahl, die die Anzahl der Vektoren mit den nächsten Nachbarn angibt, die zurückgegeben werden sollen. + ``muss ein deklariertes Feld vom Typ angeben`VECTOR`. + ``field gibt einen der Einträge für die `PARAM` Tabelle des `FT.AGGREGATE` Befehls `FT.SEARCH` or an. Dieser Parameter ist der Referenzvektorwert für Entfernungsberechnungen. Der Wert des Vektors wird in den `PARAM` Wert im *Little-Endian-Binärformat IEEE 754* codiert (genauso codiert wie bei einem HASH-Vektorfeld) + Bei Vektorindizes des Typs HNSW kann die optionale `EF_RUNTIME` Klausel verwendet werden, um den Standardwert des Parameters zu überschreiben, der bei der Indexerstellung festgelegt wurde. `EF_RUNTIME` + Die optionale Option `` stellt einen Feldnamen für die Ergebnismenge bereit, der die berechnete Entfernung zwischen dem Referenzvektor und dem gefundenen Schlüssel enthält. Bei einer Bereichssuche werden alle Vektoren innerhalb einer bestimmten Entfernung (Radius) von einem Referenzvektor lokalisiert. Die Syntax für eine Bereichssuche lautet: ``` ::= ‘@’ ‘:’ ‘[’ ‘VECTOR_RANGE’ ( | ‘$’ ) $ ‘]’ [ ‘=’ ‘>’ ‘{’ ‘}’ ] ::= | , ::= [ ‘$yield_distance_as’ ‘:’ ] [ ‘$epsilon’ ‘:’ ] ``` Wobei Folgendes gilt: + ``ist der Name des Vektorfeldes, das durchsucht werden soll. + ` or $`ist die numerische Entfernungsgrenze für die Suche. + `$ `ist der Name des Parameters, der den Referenzvektor enthält. Der Wert des Vektors wird in den PARAM-Wert im Little-Endian-Binärformat IEEE 754 codiert (gleiche Kodierung wie für ein HASH-Vektorfeld) + Das optionale Feld `` stellt einen Feldnamen für die Ergebnismenge bereit, der die berechnete Entfernung zwischen dem Referenzvektor und den einzelnen Schlüsseln enthält. + Die optionale Option ` ` steuert die Grenze des Suchvorgangs. Vektoren innerhalb der Entfernung ` * (1.0 + ) ` werden auf der Suche nach möglichen Ergebnissen durchquert. Die Standardeinstellung ist 0,01. ## Befehl INFO Die Vektorsuche erweitert die Befehle Valkey und Redis OSS [INFO](https://valkey.io/commands/info/) um mehrere zusätzliche Abschnitte mit Statistiken und Zählern. Bei einer Anfrage zum Abrufen des Abschnitts `SEARCH` werden alle folgenden Abschnitte abgerufen: ### `search_memory` Abschnitt | Name | Description | | --- | --- | | search\$1used\$1memory\$1bytes | Anzahl der in allen Suchdatenstrukturen verbrauchten Speicherbytes | | search\$1used\$1memory\$1human | Für Menschen lesbare Version von oben | ### `search_index_stats` Abschnitt | Name | Description | | --- | --- | | search\$1number\$1of\$1indexes | Anzahl der erstellten Indizes | | search\$1num\$1fulltext\$1indexes | Anzahl der Nicht-Vektor-Felder in allen Indizes | | search\$1num\$1vector\$1indexes | Anzahl der Vektorfelder in allen Indizes | | search\$1num\$1hash\$1indexes | Anzahl der Indizes für Schlüssel vom Typ HASH | | search\$1num\$1json\$1indexes | Anzahl der Indizes für Schlüssel vom Typ JSON | | search\$1total\$1indexed\$1keys | Gesamtzahl der Schlüssel in allen Indizes | | search\$1total\$1indexed\$1vectors | Gesamtzahl der Vektoren in allen Indizes | | search\$1total\$1indexed\$1hash\$1keys | Gesamtzahl der Schlüssel des Typs HASH in allen Indizes | | search\$1total\$1indexed\$1json\$1keys | Gesamtzahl der Schlüssel vom Typ JSON in allen Indizes | | search\$1total\$1index\$1size | Von allen Indizes verwendete Bytes | | search\$1total\$1fulltext\$1index\$1size | Bytes, die von Indexstrukturen verwendet werden, die keine Vektoren sind | | search\$1total\$1vector\$1index\$1size | Von Vektorindexstrukturen verwendete Bytes | | search\$1max\$1index\$1lag\$1ms | Verzögerung bei der Aufnahme während der letzten Batch-Aktualisierung | ### `search_ingestion` Abschnitt | Name | Description | | --- | --- | | search\$1background\$1indexing\$1status | Status der Einnahme. NO\$1ACTIVITYbedeutet untätig. Andere Werte deuten darauf hin, dass sich Schlüssel im Prozess der Aufnahme befinden. | | search\$1ingestion\$1paused | Außer beim Neustart sollte dies immer „nein“ sein. | ### `search_backfill` Abschnitt **Anmerkung** Einige der in diesem Abschnitt dokumentierten Felder sind nur sichtbar, wenn gerade ein Backfill im Gange ist. | Name | Description | | --- | --- | | search\$1num\$1active\$1backfills | Anzahl der aktuellen Backfill-Aktivitäten | | search\$1backfills\$1pausiert | Außer wenn nicht genügend Speicher zur Verfügung steht, sollte dies immer „nein“ sein. | | search\$1current\$1backfill\$1progress\$1percentage | % Abschluss (0-100) der aktuellen Auffüllung | ### `search_query` Abschnitt | Name | Description | | --- | --- | | search\$1num\$1active\$1queries | Anzahl der Befehle und, die derzeit ausgeführt werden FT.SEARCH FT.AGGREGATE | ## Sicherheit bei der Vektorsuche Die Sicherheitsmechanismen von [ACL (Access Control Lists)](https://valkey.io/topics/acl/) sowohl für den Befehls- als auch für den Datenzugriff wurden erweitert, um die Suchfunktion zu kontrollieren. Die ACL-Steuerung einzelner Suchbefehle wird vollständig unterstützt. Eine neue ACL-Kategorie`@search`,, wird bereitgestellt, und viele der vorhandenen Kategorien (`@fast``@read`,`@write`, usw.) wurden aktualisiert, um die neuen Befehle aufzunehmen. Suchbefehle ändern keine Schlüsseldaten, was bedeutet, dass die bestehende ACL-Maschinerie für den Schreibzugriff erhalten bleibt. Die Zugriffsregeln für HASH- und JSON-Operationen werden durch das Vorhandensein eines Indexes nicht verändert; auf diese Befehle wird weiterhin die normale Zugriffskontrolle auf Schlüsselebene angewendet. Der Zugriff auf Suchbefehle mit einem Index wird ebenfalls über ACL gesteuert. Zugriffsprüfungen werden auf der Ebene des gesamten Indexes durchgeführt, nicht auf der Ebene einzelner Schlüssel. Das bedeutet, dass einem Benutzer nur dann Zugriff auf einen Index gewährt wird, wenn dieser Benutzer berechtigt ist, auf alle möglichen Schlüssel in der Schlüsselraumpräfixliste dieses Indexes zuzugreifen. Mit anderen Worten, der tatsächliche Inhalt eines Indexes steuert den Zugriff nicht. Vielmehr ist es der theoretische Inhalt eines Indexes, wie er in der Präfixliste definiert ist, der für die Sicherheitsüberprüfung verwendet wird. Es kann leicht passieren, dass ein Benutzer Lese- und and/or Schreibzugriff auf einen Schlüssel hat, aber nicht auf einen Index zugreifen kann, der diesen Schlüssel enthält. Beachten Sie, dass nur Lesezugriff auf den Schlüsselraum erforderlich ist, um einen Index zu erstellen oder zu verwenden. Das Vorhandensein oder Fehlen von Schreibzugriff wird nicht berücksichtigt. Weitere Informationen zur Verwendung ACLs mit MemoryDB finden Sie unter [Benutzer mit Zugriffskontrolllisten authentifizieren](https://docs.aws.amazon.com/memorydb/latest/devguide/clusters.acls.html) (). ACLs # Anwendungsfälle Im Folgenden finden Sie Anwendungsfälle der Vektorsuche. ## Retrieval Augmented Generation (RAG) Retrieval Augmented Generation (RAG) nutzt die Vektorsuche, um relevante Passagen aus einem großen Datenkorpus abzurufen und so ein großes Sprachmodell (LLM) zu erweitern. Konkret bettet ein Encoder den Eingabekontext und die Suchanfrage in Vektoren ein und verwendet dann die ungefähre Suche nach dem nächsten Nachbarn, um semantisch ähnliche Passagen zu finden. Diese abgerufenen Passagen werden mit dem ursprünglichen Kontext verkettet, um dem LLM zusätzliche relevante Informationen zur Verfügung zu stellen, damit der Benutzer eine genauere Antwort erhält. ![\[Grafik des Ablaufs von Retrieval Augmented Generation\]](http://docs.aws.amazon.com/de_de/memorydb/latest/devguide/images/RAG.png) ## Dauerhafter semantischer Cache Semantisches Caching ist ein Prozess zur Reduzierung der Rechenkosten durch das Speichern früherer Ergebnisse aus dem FM. Durch die Wiederverwendung früherer Ergebnisse aus früheren Inferenzen, anstatt sie neu zu berechnen, reduziert das semantische Caching den Rechenaufwand bei der Inferenz durch. FMs MemoryDB ermöglicht dauerhaftes semantisches Caching, wodurch der Datenverlust Ihrer früheren Schlussfolgerungen vermieden wird. Auf diese Weise können Ihre generativen KI-Anwendungen innerhalb einstelliger Millisekunden mit Antworten auf frühere semantisch ähnliche Fragen antworten und gleichzeitig die Kosten senken, indem unnötige LLM-Schlussfolgerungen vermieden werden. ![\[Workflow-Diagramm, das den Foundation Model-Prozess zeigt.\]](http://docs.aws.amazon.com/de_de/memorydb/latest/devguide/images/FM.png) + **Semantischer Suchtreffer** — Wenn die Anfrage eines Kunden aufgrund eines definierten Ähnlichkeitswerts einer vorherigen Frage semantisch ähnlich ist, gibt der FM-Pufferspeicher (MemoryDB) die Antwort auf die vorherige Frage in Schritt 4 zurück und ruft das FM nicht in Schritt 3 auf. Dadurch werden die Latenz und die damit verbundenen Kosten des Foundation Model (FM) vermieden und der Kunde erhält ein schnelleres Erlebnis. + **Fehlende semantische Suche** — Wenn die Anfrage eines Kunden aufgrund eines definierten Ähnlichkeitswerts einer vorherigen Anfrage semantisch nicht ähnlich ist, ruft ein Kunde den FM an, um dem Kunden in Schritt 3a eine Antwort zu senden. Die vom FM generierte Antwort wird dann als Vektor in MemoryDB für future Abfragen gespeichert (Schritt 3b), um die FM-Kosten für semantisch ähnliche Fragen zu minimieren. In diesem Ablauf würde Schritt 4 nicht aufgerufen werden, da es für die ursprüngliche Abfrage keine semantisch ähnliche Frage gab. ## Betrugserkennung Die Betrugserkennung, eine Form der Anomalieerkennung, stellt gültige Transaktionen als Vektoren dar und vergleicht gleichzeitig die Vektordarstellungen neuer Nettotransaktionen. Betrug wird aufgedeckt, wenn diese Netto-Neutransaktionen nur eine geringe Ähnlichkeit mit den Vektoren aufweisen, die die gültigen Transaktionsdaten darstellen. Auf diese Weise kann Betrug aufgedeckt werden, indem normales Verhalten modelliert wird, anstatt zu versuchen, jeden möglichen Betrugsfall vorherzusagen. MemoryDB ermöglicht es Unternehmen, dies in Zeiten mit hohem Durchsatz zu tun, mit minimalen Fehlalarmen und Latenz im einstelligen Millisekundenbereich. ![\[Workflow-Diagramm, das den Prozess zur Betrugserkennung zeigt.\]](http://docs.aws.amazon.com/de_de/memorydb/latest/devguide/images/fraud-detection.png) ## Andere Anwendungsfälle + **Empfehlungsmaschinen** können Benutzer nach ähnlichen Produkten oder Inhalten suchen, indem sie Artikel als Vektoren darstellen. Die Vektoren werden durch die Analyse von Attributen und Mustern erstellt. Auf der Grundlage von Benutzermustern und -attributen können Benutzern neue unsichtbare Objekte empfohlen werden, indem die ähnlichsten Vektoren gefunden werden, die bereits positiv bewertet wurden und auf den Benutzer abgestimmt sind. + **Dokumentensuchmaschinen** stellen Textdokumente als dichte Zahlenvektoren dar und erfassen so semantische Bedeutungen. Bei der Suche wandelt die Suchmaschine eine Suchabfrage in einen Vektor um und findet Dokumente, deren Vektoren der Anfrage am ähnlichsten sind. Dabei wird die ungefähre Suche nach dem nächsten Nachbarn verwendet. Dieser Ansatz zur Vektorähnlichkeit ermöglicht den Abgleich von Dokumenten anhand ihrer Bedeutung und nicht nur anhand übereinstimmender Stichwörter. # 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: | Item | Maximaler Wert | | --- | --- | | Anzahl der Dimensionen in einem Vektor | 32768 | | Anzahl der Indizes, die erstellt werden können | 10 | | Anzahl der Felder in einem Index | 50 | | FT.SEARCH- und FT.AGGREGATE TIMEOUT-Klausel (Millisekunden) | 10000 | | Anzahl der Pipeline-Stufen im Befehl FT.AGGREGATE | 32 | | Anzahl der Felder in der FT.AGGREGATE LOAD-Klausel | 1024 | | Anzahl der Felder in der FT.AGGREGATE GROUPBY-Klausel | 16 | | Anzahl der Felder in der FT.AGGREGATE SORTBY-Klausel | 16 | | Anzahl der Parameter in der FT.AGGREGATE PARAM-Klausel | 32 | | HNSW M-Parameter | 512 | | HNSW EF\$1KONSTRUKTIONSPARAMETER | 4096 | | HNSW EF\$1RUNTIME-Parameter | 4096 | ## 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 Multi-AZ-Transaktionsprotokoll gelesen 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 eines [FT.CREATE-Befehls](https://docs.aws.amazon.com/memorydb/latest/devguide/vector-search-commands-ft.create.html) durch das System für jeden definierten Index. Beachten Sie, dass der Knoten für Anwendungsoperationen verfügbar ist, sobald die Daten wiederhergestellt sind, aber wahrscheinlich noch 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 VektorsucheIndizes und der OSS-Schlüsselraum von Valkey und Redis](vector-search-overview.md#vector-search-indexes-keyspaces) 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. ## Snapshot und Live-Migration import/export 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 RDB-Datei neu erstellt wird. RDB-Dateien, die keine Indizes enthalten, sind auf diese Weise jedoch nicht eingeschränkt. Somit können Daten innerhalb eines Vorschau-Clusters in Nicht-Vorschau-Cluster exportiert werden, 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 das Speichern von Vektoren in HASH- oder 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](https://aws.amazon.com/bedrock/titan/) 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 Abrufanforderungen mit hoher Dimensionalität and/or , während niedrige M-Parameter besser für niedrige Abrufanforderungen mit niedriger and/or Dimensionalität geeignet sind. 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. ![\[Cluster-Einstellungen für die Vektorsuche in der AWS Konsole.\]](http://docs.aws.amazon.com/de_de/memorydb/latest/devguide/images/vector-search-cluster-settings-console.png) **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. + Vektoren: 1 M \$1 10 Blöcke = 10 Millionen Vektoren + Abmessungen: 1536 + Daten ohne Vektoren (GB): 0 GB + M-Parameter: 16 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: ![\[Der vom Vektorrechner empfohlene Knotentyp basiert auf den Eingaben im Rechner.\]](http://docs.aws.amazon.com/de_de/memorydb/latest/devguide/images/vector-calc1.png) ![\[Der Vektorrechner mit eingegebenen Werten.\]](http://docs.aws.amazon.com/de_de/memorydb/latest/devguide/images/vector-calc2.png) In diesem Beispiel sucht der Vektorrechner anhand der angegebenen Parameter nach dem kleinsten [MemoryDB-R7G-Knotentyp](https://aws.amazon.com/memorydb/pricing/), 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. Die Rekonstruktion des HNSW-Graphen würde dazu beitragen, optimale Knotenverbindungen für qualitativ hochwertige Vektorsuchergebnisse zu schaffen. ## Nicht genügend Speicher beim Auffüllen Ähnlich wie bei den OSS-Schreiboperationen von Valkey und Redis unterliegt ein Index-Backfill 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 Befehle`FT.CREATE`,, `FT.DROPINDEX` `FT.ALIASADD``FT.ALIASDEL`, und `FT.ALIASUPDATE` können nicht in einem Transaktionskontext ausgeführt werden, d. h. nicht innerhalb eines MULTI/EXEC Blocks oder innerhalb eines LUA- oder FUNCTION-Skripts. # Erstellen Sie einen Cluster, der für die Vektorsuche aktiviert ist Sie können einen Cluster erstellen, der für die Vektorsuche aktiviert ist, indem Sie den AWS-Managementkonsole, oder den verwenden AWS Command Line Interface. Je nach Ansatz müssen Überlegungen zur Aktivierung der Vektorsuche aktiviert werden. ## Unter Verwendung der AWS-Managementkonsole Um einen Cluster zu erstellen, für den die Vektorsuche in der Konsole aktiviert ist, müssen Sie die Vektorsuche in den **Cluster-Einstellungen** aktivieren. Die Vektorsuche ist für MemoryDB Version 7.1 in einer Single-Shard-Konfiguration verfügbar. ![\[Wenn Sie die Cluster-Einstellungen bei aktivierter Option „Vektorsuche aktivieren“ anzeigen, erhalten Sie Informationen zur Unterstützung bestimmter Versionen und Konfigurationen.\]](http://docs.aws.amazon.com/de_de/memorydb/latest/devguide/images/vs-2.png) Weitere Informationen zur Verwendung der Vektorsuche mit dem AWS-Managementkonsole finden Sie unter[Einen Cluster erstellen (Konsole)](getting-started.md#clusters.createclusters.viewdetails.cluster). ## Verwenden von AWS Command Line Interface Um einen MemoryDB-Cluster mit aktivierter Vektorsuche zu erstellen, können Sie den Befehl MemoryDB [create-cluster](https://docs.aws.amazon.com/cli/latest/reference/memorydb/create-cluster.html) verwenden, indem Sie eine unveränderliche Parametergruppe `default.memorydb-redis7.search` übergeben, um die Vektorsuchfunktionen zu aktivieren. ``` aws memorydb create-cluster \ --cluster-name \ --node-type \ --engine redis \ --engine-version 7.1 \ --num-shards 1 \ --acl-name \ --parameter-group-name default.memorydb-redis7.search ``` Optional können Sie auch eine neue Parametergruppe erstellen, um die Vektorsuche zu aktivieren, wie im folgenden Beispiel gezeigt. Weitere Informationen zu Parametergruppen [finden Sie hier](parametergroups.management.md). ``` aws memorydb create-parameter-group \ --parameter-group-name my-search-parameter-group \ --family memorydb_redis7 ``` Aktualisieren Sie als Nächstes den Parameter search-enabled in der neu erstellten Parametergruppe auf yes. ``` aws memorydb update-parameter-group \ --parameter-group-name my-search-parameter-group \ --parameter-name-values "ParameterName=search-enabled,ParameterValue=yes" ``` Sie können jetzt diese benutzerdefinierte Parametergruppe anstelle der Standardparametergruppe verwenden, um die Vektorsuche in Ihren MemoryDB-Clustern zu aktivieren. # Befehle für die Vektorsuche Im Folgenden finden Sie eine Liste der unterstützten Befehle für die Vektorsuche. **Topics** + [ # FT.CREATE ](vector-search-commands-ft.create.md) + [ # FT.SEARCH ](vector-search-commands-ft.search.md) + [ # FT.AGGREGATE ](vector-search-commands-ft.aggregate.md) + [ # FT.DROPINDEX ](vector-search-commands-ft.dropindex.md) + [ # FT.INFO ](vector-search-commands-ft.info.md) + [ # FT. \$1LISTE ](vector-search-commands-ft.list.md) + [ # FT.ALIASADD ](vector-search-commands-ft.aliasadd.md) + [ # FT.ALIASDEL ](vector-search-commands-ft.aliasdel.md) + [ # FT.ALIASUPDATE ](vector-search-commands-ft.aliasupdate.md) + [ # FT. \$1ALIASLISTE ](vector-search-commands-ft.aliaslist.md) + [ # FT.PROFILE ](vector-search-commands-ft.profile.md) + [ # FT.ERLÄUTERN ](vector-search-commands-ft.explain.md) + [ # FT.EXPLAINCLI ](vector-search-commands-ft.explain-cli.md) # FT.CREATE Erstellt einen Index und initiiert ein Auffüllen dieses Indexes. Weitere Informationen zur Indexkonstruktion finden Sie unter [Überblick über die Vektorsuche](https://docs.aws.amazon.com/memorydb/latest/devguide/vector-search-overview.html). **Syntax** ``` FT.CREATE ON HASH | JSON [PREFIX [...]] SCHEMA ( [AS ] NUMERIC | TAG [SEPARATOR ] [CASESENSITIVE] | TEXT | VECTOR [HNSW|FLAT] [ ]) )+ ``` **Schema** + Feldbezeichner: + Bei Hashschlüsseln ist die Feldkennung ein Feldname. + Bei JSON-Schlüsseln ist die Feld-ID ein JSON-Pfad. Weitere Informationen finden Sie unter [Typen von Indexfeldern](vector-search-overview.md#vector-search-index-field-types). + Feldtypen: + TAG: Weitere Informationen finden Sie unter [Tags](https://redis.io/docs/interact/search-and-query/advanced-concepts/tags/). + NUMERISCH: Das Feld enthält eine Zahl. + TEXT: Das Feld enthält einen beliebigen Datenblock. + VECTOR: Vektorfeld, das die Vektorsuche unterstützt. + Algorithmus — kann HNSW (Hierarchical Navigable Small World) oder FLAT (Brute Force) sein. + `attr_count`— Anzahl der Attribute, die als Algorithmuskonfiguration übergeben werden, dazu gehören sowohl Namen als auch Werte. + `{attribute_name} {attribute_value}`— Algorithmusspezifische key/value Paare, die die Indexkonfiguration definieren. Für den FLAT-Algorithmus sind die Attribute: Erforderlich: + DIM — Anzahl der Dimensionen im Vektor. + DISTANCE\$1METRIC — Kann einer von [L2 \$1 IP \$1 COSINE] sein. + TYPE — Vektortyp. Der einzige unterstützte Typ ist`FLOAT32`. Optional: + INITIAL\$1CAP — Die anfängliche Vektorkapazität im Index beeinflusst die Größe der Speicherzuweisung des Indexes. Für den HNSW-Algorithmus sind die Attribute: Erforderlich: + TYPE — Vektortyp. Der einzige unterstützte Typ ist`FLOAT32`. + DIM — Vektordimension, angegeben als positive Ganzzahl. Maximum: 32768 + DISTANCE\$1METRIC — Kann einer von [L2 \$1 IP \$1 COSINE] sein. Optional: + INITIAL\$1CAP — Die anfängliche Vektorkapazität im Index beeinflusst die Größe der Speicherzuweisung des Indexes. Der Standardwert ist 1024. + M — Anzahl der maximal zulässigen ausgehenden Kanten für jeden Knoten im Diagramm in jeder Ebene. Auf Ebene Null beträgt die maximale Anzahl von ausgehenden Kanten 2 M. Die Standardeinstellung ist 16, das Maximum ist 512. + EF\$1CONSTRUCTION — steuert die Anzahl der Vektoren, die bei der Indexerstellung untersucht werden. Höhere Werte für diesen Parameter verbessern die Rückrufrate auf Kosten längerer Indexerstellungszeiten. Der Standardwert ist 200. Der Maximalwert ist 4096. + EF\$1RUNTIME — steuert die Anzahl der Vektoren, die bei Abfrageoperationen untersucht werden. Höhere Werte für diesen Parameter können zu einem besseren Abruf führen, allerdings auf Kosten längerer Abfragezeiten. Der Wert dieses Parameters kann für jede Abfrage außer Kraft gesetzt werden. Standardwert: 10. Der Höchstwert ist 4096. **Ergebnis** Gibt eine einfache Zeichenfolge zurück: OK-Meldung oder Fehlerantwort. **Beispiele** **Anmerkung** Im folgenden Beispiel werden Argumente verwendet, die für [Valkey-Cli](https://valkey.io/topics/cli/) typisch sind, wie z. B. das Entfernen von Anführungszeichen und das Entfernen von Escapes von Daten, bevor sie an Valkey oder Redis OSS gesendet werden. Um andere Programmiersprachenclients (Python, Ruby, C\$1 usw.) zu verwenden, befolgen Sie die Regeln dieser Umgebungen für den Umgang mit Zeichenketten und Binärdaten. [Weitere Informationen zu unterstützten Clients finden Sie unter Tools to Build On AWS](https://aws.amazon.com/developer/tools/) **Example 1: Erstellen Sie einige Indizes** Erstellen Sie einen Index für Vektoren der Größe 2 ``` FT.CREATE hash_idx1 ON HASH PREFIX 1 hash: SCHEMA vec AS VEC VECTOR HNSW 6 DIM 2 TYPE FLOAT32 DISTANCE_METRIC L2 OK ``` Erstellen Sie einen 6-dimensionalen JSON-Index mit dem HNSW-Algorithmus: ``` FT.CREATE json_idx1 ON JSON PREFIX 1 json: SCHEMA $.vec AS VEC VECTOR HNSW 6 DIM 6 TYPE FLOAT32 DISTANCE_METRIC L2 OK ``` **Example Beispiel 2: Füllen Sie einige Daten aus** Die folgenden Befehle sind so formatiert, dass sie als Argumente für das Redis-CLI-Terminalprogramm ausgeführt werden können. Entwickler, die Programmiersprachen-Clients (wie Python, Ruby, C\$1 usw.) verwenden, müssen die Regeln ihrer Umgebung für den Umgang mit Zeichenketten und Binärdaten befolgen. Einige Hash- und JSON-Daten erstellen: ``` HSET hash:0 vec "\x00\x00\x00\x00\x00\x00\x00\x00" HSET hash:1 vec "\x00\x00\x00\x00\x00\x00\x80\xbf" JSON.SET json:0 . '{"vec":[1,2,3,4,5,6]}' JSON.SET json:1 . '{"vec":[10,20,30,40,50,60]}' JSON.SET json:2 . '{"vec":[1.1,1.2,1.3,1.4,1.5,1.6]}' ``` Beachten Sie Folgendes: + Die Schlüssel der Hash- und JSON-Daten haben die Präfixe ihrer Indexdefinitionen. + Die Vektoren befinden sich an den entsprechenden Pfaden der Indexdefinitionen. + Die Hash-Vektoren werden als Hex-Daten eingegeben, während die JSON-Daten als Zahlen eingegeben werden. + Die Vektoren haben die entsprechenden Längen, die zweidimensionalen Hash-Vektoreinträge haben Hex-Daten im Wert von zwei Fließkommazahlen, die sechsdimensionalen JSON-Vektoreinträge haben sechs Zahlen. **Example Beispiel 3: Löschen Sie einen Index und erstellen Sie ihn neu** ``` FT.DROPINDEX json_idx1 OK FT.CREATE json_idx1 ON JSON PREFIX 1 json: SCHEMA $.vec AS VEC VECTOR FLAT 6 DIM 6 TYPE FLOAT32 DISTANCE_METRIC L2 OK ``` Beachten Sie, dass der neue JSON-Index den `FLAT` Algorithmus anstelle des `HNSW` Algorithmus verwendet. Beachten Sie auch, dass die vorhandenen JSON-Daten neu indexiert werden: ``` FT.SEARCH json_idx1 "*=>[KNN 100 @VEC $query_vec]" PARAMS 2 query_vec "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00" DIALECT 2 1) (integer) 3 2) "json:2" 3) 1) "__VEC_score" 2) "11.11" 3) "$" 4) "[{\"vec\":[1.1, 1.2, 1.3, 1.4, 1.5, 1.6]}]" 4) "json:0" 5) 1) "__VEC_score" 2) "91" 3) "$" 4) "[{\"vec\":[1.0, 2.0, 3.0, 4.0, 5.0, 6.0]}]" 6) "json:1" 7) 1) "__VEC_score" 2) "9100" 3) "$" 4) "[{\"vec\":[10.0, 20.0, 30.0, 40.0, 50.0, 60.0]}]" ``` # FT.SEARCH Verwendet den angegebenen Abfrageausdruck, um Schlüssel innerhalb eines Index zu finden. Sobald sie gefunden wurden, kann and/or die Anzahl der indizierten Felder innerhalb dieser Schlüssel zurückgegeben werden. Weitere Informationen finden Sie unter [Abfrageausdruck für die Vektorsuche](https://docs.aws.amazon.com/memorydb/latest/devguide/vector-search-overview.html#vector-search-query-expression). Informationen zum Erstellen von Daten zur Verwendung in diesen Beispielen finden Sie im Befehl [FT.CREATE.](https://docs.aws.amazon.com/memorydb/latest/devguide/vector-search-commands-ft.create.html) **Syntax** ``` FT.SEARCH [RETURN ( [AS ])+] [TIMEOUT timeout] [PARAMS [ ]] [LIMIT ] [COUNT] ``` + RETURN: Diese Klausel identifiziert, welche Felder eines Schlüssels zurückgegeben werden. Die optionale AS-Klausel für jedes Feld überschreibt den Namen des Felds im Ergebnis. Es können nur Felder angegeben werden, die für diesen Index deklariert wurden. + LIMIT: : Diese Klausel ermöglicht die Paginierung, da nur die Schlüssel zurückgegeben werden, die den Offset- und Count-Werten entsprechen. Wenn diese Klausel weggelassen wird, wird standardmäßig „LIMIT 0 10“ verwendet, d. h. es werden nur maximal 10 Schlüssel zurückgegeben. + PARAMS: Zweimal so viele Schlüssel-Wert-Paare. Auf key/value Parameterpaare kann innerhalb des Abfrageausdrucks verwiesen werden. Weitere Informationen finden Sie unter [Abfrageausdruck für die Vektorsuche](https://docs.aws.amazon.com/memorydb/latest/devguide/vector-search-overview.html#vector-search-query-expression). + COUNT: Diese Klausel unterdrückt die Rückgabe des Inhalts von Schlüsseln, es wird nur die Anzahl der Schlüssel zurückgegeben. Dies ist ein Alias für „LIMIT 0 0". **Ergebnis** Gibt ein Array oder eine Fehlerantwort zurück. + Wenn der Vorgang erfolgreich abgeschlossen wird, wird ein Array zurückgegeben. Das erste Element ist die Gesamtzahl der Schlüssel, die der Abfrage entsprechen. Die übrigen Elemente sind Paare aus Schlüsselname und Feldliste. Die Feldliste ist ein weiteres Array, das Paare von Feldnamen und Werten umfasst. + Wenn der Index gerade wieder aufgefüllt wird, gibt der Befehl sofort eine Fehlerantwort zurück. + Wenn das Timeout erreicht ist, gibt der Befehl eine Fehlerantwort zurück. **Beispiel: Führen Sie einige Suchanfragen durch** **Anmerkung** Das folgende Beispiel verwendet Argumente, die für [Valkey-Cli](https://valkey.io/topics/cli/) typisch sind, wie z. B. das Entfernen von Anführungszeichen und das Entfernen von Escapes von Daten, bevor sie an Valkey oder Redis OSS gesendet werden. Um andere Programmiersprachenclients (Python, Ruby, C\$1 usw.) zu verwenden, befolgen Sie die Regeln dieser Umgebungen für den Umgang mit Zeichenketten und Binärdaten. [Weitere Informationen zu unterstützten Clients finden Sie unter Tools to Build On AWS](https://aws.amazon.com/developer/tools/) **Eine Hash-Suche** ``` FT.SEARCH hash_idx1 "*=>[KNN 2 @VEC $query_vec]" PARAMS 2 query_vec "\x00\x00\x00\x00\x00\x00\x00\x00" DIALECT 2 1) (integer) 2 2) "hash:0" 3) 1) "__VEC_score" 2) "0" 3) "vec" 4) "\x00\x00\x00\x00\x00\x00\x00\x00" 4) "hash:1" 5) 1) "__VEC_score" 2) "1" 3) "vec" 4) "\x00\x00\x00\x00\x00\x00\x80\xbf" ``` Dies führt zu zwei Ergebnissen, sortiert nach ihrer Punktzahl, die der Entfernung vom Abfragevektor (eingegeben als Hexadezimalwert) entspricht. **JSON-Suchen** ``` FT.SEARCH json_idx1 "*=>[KNN 2 @VEC $query_vec]" PARAMS 2 query_vec "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00" DIALECT 2 1) (integer) 2 2) "json:2" 3) 1) "__VEC_score" 2) "11.11" 3) "$" 4) "[{\"vec\":[1.1, 1.2, 1.3, 1.4, 1.5, 1.6]}]" 4) "json:0" 5) 1) "__VEC_score" 2) "91" 3) "$" 4) "[{\"vec\":[1.0, 2.0, 3.0, 4.0, 5.0, 6.0]}]" ``` Dies führt zu den beiden Ergebnissen, die sich am nächsten kommen, sortiert nach ihrer Punktzahl. Beachten Sie, dass die JSON-Vektorwerte in Gleitkommazahlen umgewandelt werden und es sich bei dem Abfragevektor immer noch um Vektordaten handelt. Beachten Sie außerdem, dass es nur zwei Ergebnisse gibt, da der `KNN` Parameter 2 ist. Ein größerer Wert gibt mehr Ergebnisse zurück: ``` FT.SEARCH json_idx1 "*=>[KNN 100 @VEC $query_vec]" PARAMS 2 query_vec "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00" DIALECT 2 1) (integer) 3 2) "json:2" 3) 1) "__VEC_score" 2) "11.11" 3) "$" 4) "[{\"vec\":[1.1, 1.2, 1.3, 1.4, 1.5, 1.6]}]" 4) "json:0" 5) 1) "__VEC_score" 2) "91" 3) "$" 4) "[{\"vec\":[1.0, 2.0, 3.0, 4.0, 5.0, 6.0]}]" 6) "json:1" 7) 1) "__VEC_score" 2) "9100" 3) "$" 4) "[{\"vec\":[10.0, 20.0, 30.0, 40.0, 50.0, 60.0]}]" ``` # FT.AGGREGATE Es ist eine Obergruppe des Befehls FT.SEARCH und ermöglicht eine erhebliche zusätzliche Verarbeitung der durch den Abfrageausdruck ausgewählten Schlüssel. **Syntax** ``` FT.AGGREGATE index query [LOAD * | [count field [field ...]]] [TIMEOUT timeout] [PARAMS count name value [name value ...]] [FILTER expression] [LIMIT offset num] [GROUPBY count property [property ...] [REDUCE function count arg [arg ...] [AS name] [REDUCE function count arg [arg ...] [AS name] ...]] ...]] [SORTBY count [ property ASC | DESC [property ASC | DESC ...]] [MAX num]] [APPLY expression AS name] ``` + Die Klauseln FILTER, LIMIT, GROUPBY, SORTBY und APPLY können mehrfach in beliebiger Reihenfolge wiederholt und beliebig miteinander vermischt werden. Sie werden in der angegebenen Reihenfolge angewendet, wobei die Ausgabe einer Klausel die Eingabe der nächsten Klausel speist. + In der obigen Syntax ist eine „Eigenschaft“ entweder ein Feld, das im Befehl [FT.CREATE](https://docs.aws.amazon.com/memorydb/latest/devguide/vector-search-commands-ft.create.html) für diesen Index deklariert wurde, ODER die Ausgabe einer vorherigen APPLY-Klausel oder REDUCE-Funktion. + Die LOAD-Klausel ist auf das Laden von Feldern beschränkt, die im Index deklariert wurden. „LOAD \$1“ lädt alle im Index deklarierten Felder. + Die folgenden Reducer-Funktionen werden unterstützt: COUNT, COUNT\$1DISTINCTISH, SUM, MIN, MAX, AVG, STDDEV, QUANTILE, TOLIST, FIRST\$1VALUE und RANDOM\$1SAMPLE. [Weitere Informationen finden Sie unter Aggregationen](https://redis.io/docs/interact/search-and-query/search/aggregations/) + LIMIT : Speichert Datensätze ab und bis zu, alle anderen Datensätze werden verworfen. + PARAMS: Zweimal so viele Schlüssel-Wert-Paare. Auf key/value Parameterpaare kann innerhalb des Abfrageausdrucks verwiesen werden. **Ergebnis** Gibt ein Array oder eine Fehlerantwort zurück. + Wenn der Vorgang erfolgreich abgeschlossen wird, wird ein Array zurückgegeben. Das erste Element ist eine Ganzzahl ohne besondere Bedeutung (sollte ignoriert werden). Die verbleibenden Elemente sind die Ergebnisse, die von der letzten Stufe ausgegeben wurden. Jedes Element ist ein Array von Feldnamen- und Wertepaaren. + Wenn der Index gerade wieder aufgefüllt wird, gibt der Befehl sofort eine Fehlerantwort zurück. + Wenn das Timeout erreicht ist, gibt der Befehl eine Fehlerantwort zurück. # FT.DROPINDEX Löscht einen Index. Die Indexdefinition und der zugehörige Inhalt werden gelöscht. Schlüssel sind davon nicht betroffen. **Syntax** ``` FT.DROPINDEX ``` **Ergebnis** Gibt eine einfache OK-Meldung oder eine Fehlerantwort zurück. # FT.INFO **Syntax** ``` FT.INFO ``` Die Ausgabe der FT.INFO-Seite ist ein Array von Schlüssel-Wert-Paaren, wie in der folgenden Tabelle beschrieben: | Key (Schlüssel) | Werttyp | Description | | --- | --- | --- | | index\$1name | Zeichenfolge | Name des Indexes | | creation\$1timestamp | Ganzzahl | Zeitstempel der Erstellungszeit im UNIX-Stil | | Schlüsseltyp | Zeichenfolge | HASH oder JSON | | key\$1prefixes | Zeichenfolgen-Array | Wichtige Präfixe für diesen Index | | fields | Reihe von Feldinformationen | Felder dieses Indexes | | Space\$1Usage | Ganzzahl | Von diesem Index verwendete Speicherbytes | | fullext\$1space\$1usage | Ganzzahl | Speicherbytes, die von Feldern verwendet werden, die keine Vektoren sind | | vector\$1space\$1usage | Ganzzahl | Von Vektorfeldern verwendete Speicherbytes | | num\$1docs | Ganzzahl | Anzahl der aktuell im Index enthaltenen Schlüssel | | num\$1indexed\$1vectors | Ganzzahl | Anzahl der Vektoren, die derzeit im Index enthalten sind | | current\$1lag | Ganzzahl | Aktuelle Verzögerung bei der Aufnahme (Millisekunden) | | Backfill\$1Status | Zeichenfolge | Einer von: Abgeschlossen, InProgres Pausiert oder Fehlgeschlagen | In der folgenden Tabelle werden die Informationen für jedes Feld beschrieben: | Key (Schlüssel) | Werttyp | Description | | --- | --- | --- | | Bezeichner | Zeichenfolge | Name des Feldes | | Feldname | Zeichenfolge | Hash-Mitgliedsname oder JSON-Pfad | | type | Zeichenfolge | einer der folgenden Werte: Numerisch, Tag, Text oder Vektor | | option | Zeichenfolge | ignore | Wenn das Feld vom Typ Vector ist, werden je nach Algorithmus zusätzliche Informationen angezeigt. Für den HNSW-Algorithmus: | Key (Schlüssel) | Werttyp | Description | | --- | --- | --- | | Algorithmus | Zeichenfolge | HNSW | | data\$1type | Zeichenfolge | FLOAT32 | | distanz\$1metrisch | Zeichenfolge | einer von: L2, IP oder Cosine | | initial\$1capacity | Ganzzahl | Anfangsgröße des Vektorfeldindexes | | aktuelle\$1Kapazität | Ganzzahl | Aktuelle Größe des Vektorfeldindexes | | maximum\$1edges | Ganzzahl | M-Parameter bei der Erstellung | | ef\$1construction | Ganzzahl | EF\$1CONSTRUCTION-Parameter bei der Erstellung | | ef\$1runtime | Ganzzahl | EF\$1RUNTIME-Parameter bei der Erstellung | Für den FLAT-Algorithmus: | Key (Schlüssel) | Werttyp | Description | | --- | --- | --- | | Algorithmus | Zeichenfolge | WOHNUNG | | data\$1type | Zeichenfolge | FLOAT32 | | distance\$1metric | Zeichenfolge | einer von: L2, IP oder Cosine | | initial\$1capacity | Ganzzahl | Anfangsgröße des Vektorfeldindexes | | aktuelle\$1Kapazität | Ganzzahl | Aktuelle Größe des Vektorfeldindexes | # FT. \$1LISTE Listet alle Indizes auf. **Syntax** ``` FT._LIST ``` **Ergebnis** Gibt ein Array von Indexnamen zurück # FT.ALIASADD Fügen Sie einen Alias für einen Index hinzu. Der neue Aliasname kann überall verwendet werden, wo ein Indexname erforderlich ist. **Syntax** ``` FT.ALIASADD ``` **Ergebnis** Gibt eine einfache Zeichenfolge, eine OK-Nachricht oder eine Fehlerantwort zurück. # FT.ALIASDEL Löscht einen vorhandenen Alias für einen Index. **Syntax** ``` FT.ALIASDEL ``` **Ergebnis** Gibt eine einfache Zeichenfolge, eine OK-Nachricht oder eine Fehlerantwort zurück. # FT.ALIASUPDATE Aktualisieren Sie einen vorhandenen Alias so, dass er auf einen anderen physischen Index verweist. Dieser Befehl wirkt sich nur auf future Verweise auf den Alias aus. Derzeit laufende Operationen (FT.SEARCH, FT.AGGREGATE) sind von diesem Befehl nicht betroffen. **Syntax** ``` FT.ALIASUPDATE ``` **Ergebnis** Gibt eine einfache OK-Meldung oder eine Fehlerantwort zurück. # FT. \$1ALIASLISTE Listet die Index-Aliase auf. **Syntax** ``` FT._ALIASLIST ``` **Ergebnis** Gibt ein Array zurück, das der Größe der Anzahl der aktuellen Aliase entspricht. Jedes Element des Arrays ist das Alias-Indexpaar. # FT.PROFILE Führen Sie eine Abfrage aus und geben Sie Profilinformationen zu dieser Abfrage zurück. **Syntax** ``` FT.PROFILE SEARCH | AGGREGATE [LIMITED] QUERY ``` **Ergebnis** Ein Array mit zwei Elementen. Das erste Element ist das Ergebnis des `FT.AGGREGATE` Befehls `FT.SEARCH` oder, für den ein Profil erstellt wurde. Das zweite Element besteht aus einer Reihe von Leistungs- und Profilerstellungsinformationen. # FT.ERLÄUTERN Analysieren Sie eine Abfrage und geben Sie Informationen darüber zurück, wie diese Abfrage analysiert wurde. **Syntax** ``` FT.EXPLAIN ``` **Ergebnis** Eine Zeichenfolge, die die analysierten Ergebnisse enthält. # FT.EXPLAINCLI Entspricht dem Befehl FT.EXPLAIN, außer dass die Ergebnisse in einem anderen Format angezeigt werden, das mit der Redis-CLI nützlicher ist. **Syntax** ``` FT.EXPLAINCLI ``` **Ergebnis** Eine Zeichenfolge, die die analysierten Ergebnisse enthält.