

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.

# Erste Schritte mit Vector Search
<a name="vector-search"></a>

Amazon ElastiCache for Valkey unterstützt die Vektorsuche, sodass Sie Milliarden von hochdimensionalen Vektoreinbettungen mit Latenzen von nur Mikrosekunden und einem Abruf von mehr als 99% im Speicher speichern, suchen und aktualisieren können. ElastiCache for Valkey bietet Funktionen zum Indizieren, Suchen und Aktualisieren von Milliarden von hochdimensionalen Vektoreinbettungen von bekannten Anbietern wie Amazon Bedrock, Amazon SageMaker, Anthropic oder OpenAI für schnelles Suchen und Abrufen. Die Vektorsuche für Amazon ElastiCache ist ideal für Anwendungsfälle, in denen Spitzenleistung und Skalierbarkeit die wichtigsten Auswahlkriterien sind. Dazu gehören semantisches Caching, Generierung mit erweitertem Abruf, Empfehlungen in Echtzeit, Personalisierung und Erkennung von Anomalien. 

Die Vektorsuche kann in Verbindung mit anderen Funktionen verwendet werden, um Ihre Anwendungen zu verbessern. ElastiCache Die Vektorsuche nach ElastiCache ist in Valkey Version 8.2 auf knotenbasierten Clustern in allen [AWS Regionen](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/) ohne zusätzliche Kosten verfügbar. Erstellen Sie zunächst einen neuen Valkey 8.2-Cluster mit dem SDK oder [AWS-Managementkonsole](https://console.aws.amazon.com/elasticache/).AWSAWS CLI Sie können die Vektorsuche auch in Ihrem vorhandenen Cluster verwenden, indem Sie mit [wenigen Klicks](VersionManagement.HowTo.md) und ohne Ausfallzeiten von einer beliebigen früheren Version von Valkey oder Redis OSS auf Valkey 8.2 aktualisieren.

# Überblick über die Vektorsuche
<a name="vector-search-overview"></a>

ElastiCache for Valkey bietet Funktionen zum Indizieren, Suchen und Aktualisieren von Milliarden von hochdimensionalen Vektoreinbettungen. Die Vektorsuche ermöglicht es Ihnen, Sekundärindizes für eine effiziente und skalierbare Suche zu erstellen, zu verwalten und zu verwenden. Jeder Vektorsuchvorgang bezieht sich auf einen einzelnen Index. Indexoperationen gelten nur für den angegebenen Index. Eine beliebige Anzahl von Vorgängen kann jederzeit für jeden Index ausgeführt werden, mit Ausnahme von Vorgängen zum Erstellen und Löschen von Indizes. Auf Clusterebene können mehrere Operationen für mehrere Indizes gleichzeitig ausgeführt werden.

In diesem Dokument sind die Begriffe Schlüssel, Zeile und Datensatz identisch und werden synonym verwendet. In ähnlicher Weise werden auch die Begriffe Spalte, Feld, Pfad und Element synonym verwendet.

Der `FT.CREATE` Befehl kann verwendet werden, um einen Index für eine Teilmenge von Schlüsseln mit den angegebenen Indextypen zu erstellen. `FT.SEARCH`führt Abfragen an erstellten Indizes durch und `FT.DROPINDEX` entfernt einen vorhandenen Index und alle zugehörigen Daten. Es gibt keine speziellen Befehle zum Hinzufügen, Löschen oder Ändern indizierter Daten. Die vorhandenen `JSON` Befehle `HASH` oder, die einen Schlüssel ändern, der sich in einem Index befindet, aktualisieren den Index automatisch.

**Topics**
+ [Indizes und der Valkey OSS-Keyspace](#indexes-keyspace)
+ [Index-Feldtypen](#index-field-types)
+ [Vektor-Index-Algorithmen](#vector-index-algorithms)
+ [Sicherheit bei der Vektorsuche](#vector-search-security)

## Indizes und der Valkey OSS-Keyspace
<a name="indexes-keyspace"></a>

Indizes werden für eine Teilmenge des Valkey-OSS-Schlüsselraums erstellt und verwaltet. Der Schlüsselraum für jeden Index wird durch eine Liste von Schlüsselpräfixen definiert, die bei der Erstellung des Indexes bereitgestellt werden. Die Liste der Präfixe ist optional, und wenn sie weggelassen wird, ist der gesamte Schlüsselraum Teil dieses Indexes. Bei mehreren Indizes können unzusammenhängende oder überlappende Teilmengen des Schlüsselraums ohne Einschränkung ausgewählt werden.

Indizes werden auch so eingegeben, dass sie nur Schlüssel abdecken, die einen übereinstimmenden Typ haben. Derzeit werden Indizes nur für Typen und unterstützt. `JSON` `HASH` 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üsselraumpräfixliste eines Indexes, die nicht den angegebenen Typ haben, werden ignoriert und wirken sich nicht auf Suchvorgänge aus.

Ein Index wird aktualisiert, wenn ein Befehl eine Taste ändert, die sich innerhalb des Schlüsselraums des Indexes befindet. Valkey extrahiert automatisch die deklarierten Felder für jeden Index und aktualisiert den Index mit dem neuen Wert. Der Aktualisierungsprozess besteht aus drei Schritten. Im ersten Schritt wird der HASH- oder JSON-Schlüssel geändert und der anfragende Client wird blockiert. Der zweite Schritt wird im Hintergrund ausgeführt und aktualisiert jeden der Indizes, die den geänderten Schlüssel enthalten. Im dritten Schritt wird der Client entsperrt. Bei Abfrageoperationen, die auf derselben Verbindung wie eine Mutation ausgeführt werden, ist diese Änderung also sofort in den Suchergebnissen sichtbar. 

Die Erstellung eines Indexes ist ein mehrstufiger Prozess. Der erste Schritt besteht darin, den Befehl FT.CREATE 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 dass 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 Befehl FT.INFO gibt den Status des Backfill-Vorgangs im Feld „backfill\$1status“ zurück.

## Index-Feldtypen
<a name="index-field-types"></a>

Jeder Index hat einen bestimmten Typ, der zusammen mit der Position eines zu indizierenden Felds (Spalte) deklariert wird, wenn der Index erstellt wird. Bei `HASH` Schlüsseln ist die Position der Feldname innerhalb von. `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 drei Arten von Feldern, die im Folgenden erklärt werden:
+ **Vektorfelder** enthalten einen Zahlenvektor, der auch als Vektoreinbettung bezeichnet wird. Vektorfelder können verwendet werden, um Vektoren auf der Grundlage bestimmter Entfernungsmetriken zur Messung der Ähnlichkeit zu filtern. 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.
+ **Zahlenfelder** enthalten eine einzelne Zahl. Zahlenfelder können mit dem Bereichs-Suchoperator verwendet werden. Denn es wird erwartet`HASH`, dass das Feld den ASCII-Text einer Zahl enthält, die im Standardformat von Fest- oder Gleitkommazahlen geschrieben ist. Bei `JSON` Feldern müssen die numerischen Regeln für JSON-Zahlen befolgt werden. Unabhängig von der Darstellung innerhalb des Schlüssels wird dieses Feld zur Speicherung im Index in eine 64-Bit-Fließkommazahl umgewandelt. Da die zugrunde liegenden Zahlen aufgrund ihrer Genauigkeitseinschrä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. Tag-Felder können verwendet werden, um Abfragen nach der Äquivalenz von Tag-Werten zu filtern, wobei entweder Groß- und Kleinschreibung beachtet wird oder nicht. 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.

## Vektor-Index-Algorithmen
<a name="vector-index-algorithms"></a>

Zwei Vektorindex-Algorithmen werden in Valkey unterstützt:
+ **Flat** — 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. Flache Indizes unterstützen höhere Aufnahmegeschwindigkeiten.
+ **Hierarchical Navigable Small Worlds (HNSW)** — Der HNSW-Algorithmus ist eine Alternative, bei der annähernd engste Vektorübereinstimmungen im Austausch für wesentlich kürzere Ausführungszeiten bereitgestellt werden. 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.

In HNSW steuert der Parameter M die maximale Anzahl von Nachbarn, mit denen jeder Knoten eine Verbindung herstellen kann, wodurch die Indexdichte bestimmt wird. Ein höherer Wert von M, z. B. 32 und höher, führt zu einem stärker vernetzten Graphen, wodurch die Abruf- und Abfragegeschwindigkeit verbessert wird, da mehr Pfade existieren, um relevante Nachbarn zu erreichen. Es erhöht jedoch die Indexgröße und den Speicherverbrauch und verlangsamt die Indizierung. Ein niedrigeres M, z. B. 8 und weniger, ergibt einen kleineren faster-to-build Index mit geringerer Speicherbelegung, aber der Abruf nimmt ab und Abfragen können aufgrund weniger Verbindungen länger dauern.

Der Parameter EF\$1Construction bestimmt, wie viele mögliche Verbindungen bei der Indexerstellung ausgewertet werden. Ein höherer Wert von EF\$1Construction, z. B. 400 und höher, bedeutet, dass der Indexer mehr Pfade berücksichtigt, bevor er Nachbarn auswählt. Dies führt zu einem Diagramm, das später sowohl die Abruf- als auch die Abfrageeffizienz verbessert, jedoch auf Kosten einer langsameren Indizierung und einer höheren CPU- und Speicherauslastung während der Konstruktion. Eine niedrige EF\$1Construction, z. B. 64-120, beschleunigt die Indizierung und reduziert den Ressourcenverbrauch, aber das resultierende Diagramm kann die Anzahl der Rückrufaktionen reduzieren und Abfragen verlangsamen, selbst wenn EF\$1Runtime auf einen hohen Wert eingestellt ist.

Schließlich bestimmt EF\$1Runtime den Umfang der Suche während der Abfrage und steuert, wie viele Nachbarkandidaten zur Laufzeit untersucht werden. Ein hoher Wert erhöht den Abruf und die Genauigkeit, geht jedoch auf Kosten der Abfragelatenz und der CPU-Auslastung. Ein niedriger Wert für EF\$1Runtime macht Abfragen schneller und einfacher, allerdings mit geringerem Abruf. Im Gegensatz zu M oder EF\$1Construction hat dieser Parameter keinen Einfluss auf die Indexgröße oder die Erstellungszeit, sodass er der Parameter ist, mit dem die Kompromisse zwischen Abruf und Latenz nach der Indexerstellung abgestimmt werden können.

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. Flache Indizes unterstützen bessere Aufnahmegeschwindigkeiten als HNSW.

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 

## Sicherheit bei der Vektorsuche
<a name="vector-search-security"></a>

Die Sicherheitsmechanismen von [Valkey 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. Situationen, in denen 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, sind möglich. 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.

# Funktionen und Grenzen der Vektorsuche
<a name="vector-search-features-limits"></a>

## Verfügbarkeit der Vektorsuche
<a name="vector-search-availability"></a>

Die Vektorsuche für Amazon ElastiCache ist mit Valkey Version 8.2 auf knotenbasierten Clustern in allen AWS Regionen ohne zusätzliche Kosten verfügbar. [Sie können die Vektorsuche auch für Ihre vorhandenen Cluster verwenden, indem Sie mit wenigen Klicks und ohne Ausfallzeiten von einer beliebigen Version von Valkey oder Redis OSS auf Valkey 8.2 aktualisieren.](VersionManagement.HowTo.md)

Die Vektorsuche ist derzeit für alle ElastiCache Instance-Typen mit Ausnahme von Knoten mit Daten-Tiering verfügbar. Die Verwendung der Vektorsuche auf T2-, T3- und T4G-Instances erfordert eine Erhöhung der Speicherreserve auf mindestens 50% für Mikro- und 30% für kleine Instances. Weitere Informationen finden Sie auf [dieser Seite](redis-memory-management.md).

## Parametrische Einschränkungen
<a name="parametric-restrictions"></a>

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


**Grenzwerte für die Vektorsuche**  

| 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 TIMEOUT-Klausel (Millisekunden) | 60000 | 
| Maximal zulässige Anzahl von Präfixen pro Index | 16 | 
| Maximale Länge eines Tag-Felds | 10000 | 
| Maximale Länge eines numerischen Feldes | 256 | 
| HNSW M-Parameter | 2000000 | 
| HNSW EF\$1KONSTRUKTIONSPARAMETER | 4096 | 
| HNSW EF\$1RUNTIME-Parameter | 4096 | 

## Betriebseinschränkungen
<a name="operational-restrictions"></a>

### Persistenz und Backfilling von Indizes
<a name="index-persistence-backfilling"></a>

Der Aktualisierungsvorgang besteht aus drei Schritten. Im ersten Schritt wird der HASH- oder JSON-Schlüssel geändert und der anfragende Client wird blockiert. Der zweite Schritt wird im Hintergrund ausgeführt und aktualisiert jeden der Indizes, die den geänderten Schlüssel enthalten. Im dritten Schritt wird der Client entsperrt. Bei Abfrageoperationen, die auf derselben Verbindung wie eine Mutation ausgeführt werden, ist diese Änderung also sofort in den Suchergebnissen sichtbar. Das Einfügen oder Aktualisieren eines Schlüssels ist jedoch möglicherweise für einen kurzen Zeitraum nicht in den Suchergebnissen anderer Clients sichtbar. In Zeiten hoher Systemlast und and/or starker Mutation von Daten kann sich die Sichtbarkeitsverzögerung verlängern.

Die Vektorsuchfunktion behält die Definition von Indizes und den Inhalt der Indizes bei. Indizes für Vektorfelder werden gespeichert, aber die Indizes für TAGS und NUMERIC werden nicht gespeichert, was bedeutet, dass sie neu erstellt werden müssen, wenn sie extern geladen werden (vollständige Synchronisierung oder Neuladen). Das bedeutet, dass bei jeder Betriebsanfrage oder jedem Ereignis, das zum Starten oder Neustarten eines Knotens führt, die Indexdefinition und der Inhalt für Vektoren aus dem letzten Snapshot wiederhergestellt werden. Um dies zu initiieren, ist keine Benutzeraktion erforderlich. Bei TAGS- und NUMERIC-Indizes wird die Neuerstellung jedoch als Backfill-Vorgang durchgeführt, sobald die Daten wiederhergestellt sind. Dies entspricht funktionell der automatischen Ausführung eines FT.CREATE-Befehls 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 bevor das Auffüllen des Index abgeschlossen ist, was bedeutet, dass Backfill-Operationen wieder für Anwendungen sichtbar werden.

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

### Grenzen der Skalierung
<a name="scaling-limits"></a>

Bei Skalierungsereignissen kann es vorkommen, dass der Index bei der Migration von Daten wieder aufgefüllt wird. Dies führt zu einem geringeren Abruf von Suchanfragen.

### Snapshot import/export und Live-Migration
<a name="snapshot-import-export"></a>

Die RDB-Dateien aus dem einen Cluster mit Suchindizes können in einen anderen ElastiCache Valkey-Cluster mit Version 8.2 oder höher importiert werden. Der neue Cluster wird den Indexinhalt beim Laden der RDB-Datei neu erstellen. Das Vorhandensein von Suchindizes in einer RDB-Datei schränkt jedoch die Kompatibilität dieser Daten mit früheren Versionen von Valkey ein. Das durch die Vektorsuchfunktion definierte Format der Suchindizes wird nur von einem anderen ElastiCache Cluster mit Valkey-Version 8.2 oder höher verstanden. RDB-Dateien, die keine Indizes enthalten, sind auf diese Weise jedoch nicht eingeschränkt.

### Beim Auffüllen ist nicht genügend Arbeitsspeicher verfügbar
<a name="out-of-memory-backfill"></a>

Ähnlich wie bei Valkey-OSS-Schreiboperationen 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 möglich, einen Index zu löschen, wenn das Auffüllen aufgrund von Speichermangel unterbrochen wird.

### Transaktionen
<a name="transactions"></a>

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.

# Auswahl der geeigneten Konfiguration
<a name="choosing-configuration"></a>

In der Konsolenumgebung können ElastiCache Sie auf einfache Weise den richtigen Instance-Typ auswählen, der auf den Speicher- und CPU-Anforderungen Ihres Vektor-Workloads basiert.

## Speicherverbrauch
<a name="memory-consumption"></a>

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 sowie eine zusätzliche Kopie des Vektors im Index. Es wird empfohlen, diesen zusätzlichen Speicherverbrauch im Index einzuplanen.

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. Beachten Sie, dass Sie den Instance-Typ testen sollten, um sicherzustellen, dass er Ihren Anforderungen entspricht.

## Skalieren Sie Ihren Workload
<a name="scaling-workload"></a>

Die Vektorsuche unterstützt alle drei Skalierungsmethoden: horizontal, vertikal und Replikate. Bei der Kapazitätsskalierung verhält sich die Vektorsuche genauso wie normales Valkey, d. h. die Erhöhung des Speichers einzelner Knoten (vertikale Skalierung) oder die Erhöhung der Anzahl der Knoten (horizontale Skalierung) erhöht die Gesamtkapazität. Im Clustermodus kann der `FT.CREATE` Befehl an jeden primären Knoten des Clusters gesendet werden, und das System verteilt die neue Indexdefinition automatisch an alle Clustermitglieder.

Aus Sicht der Leistung verhält sich die Vektorsuche jedoch ganz anders als das reguläre Valkey. Die Multithread-Implementierung der Vektorsuche bedeutet zusätzliche CPUs Erträge bis hin zu linearen Steigerungen sowohl des Abfrage- als auch des Aufnahmedurchsatzes. Die horizontale Skalierung führt zu einer linearen Erhöhung des Aufnahmedurchsatzes, kann jedoch den Abfragedurchsatz verringern. Wenn zusätzlicher Abfragedurchsatz erforderlich ist, ist eine Skalierung durch Replikate oder zusätzliche CPUs Daten erforderlich.

# Befehle für die Vektorsuche
<a name="vector-search-commands"></a>

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.DROPINDEX](vector-search-commands-ft.dropindex.md)
+ [FT.INFO](vector-search-commands-ft.info.md)
+ [FT. \$1LISTE](vector-search-commands-ft.list.md)

# FT.CREATE
<a name="vector-search-commands-ft.create"></a>

Der `FT.CREATE` Befehl erstellt einen leeren Index und leitet den Backfill-Prozess ein. Jeder Index besteht aus einer Reihe von Felddefinitionen. Jede Felddefinition gibt einen Feldnamen, einen Feldtyp und einen Pfad innerhalb jedes indizierten Schlüssels an, um einen Wert des deklarierten Typs zu finden. Einige Feldtypdefinitionen haben zusätzliche Untertypbezeichner.

Bei Indizes für HASH-Schlüssel ist der Pfad derselbe wie der Name des Hash-Elements. Die optionale `AS` Klausel kann verwendet werden, um das Feld auf Wunsch umzubenennen. Das Umbenennen von Feldern ist besonders nützlich, wenn der Elementname Sonderzeichen enthält.

Bei Indizes für JSON-Schlüssel ist der Pfad ein JSON-Pfad zu den Daten des deklarierten Typs. Da der JSON-Pfad immer Sonderzeichen enthält, ist die `AS` Klausel erforderlich.

**Syntax**

```
FT.CREATE <index-name>
ON HASH | JSON
[PREFIX <count> <prefix1> [<prefix2>...]]
SCHEMA 
(<field-identifier> [AS <alias>] 
| VECTOR [HNSW|FLAT] <attr_count> [<attribute_name> <attribute_value>])
| TAG [SEPARATOR <sep>] [CASESENSITIVE] 
| NUMERIC 
)+
```

**(erforderlich):** <index-name>Dies ist der Name, den Sie Ihrem Index geben. Wenn bereits ein Index mit demselben Namen existiert, wird ein Fehler zurückgegeben.

**ON HASH \$1 JSON (optional):** Nur Schlüssel, die dem angegebenen Typ entsprechen, sind in diesem Index enthalten. Wenn es weggelassen wird, wird HASH angenommen.

**PREFIX (optional):** <prefix-count><prefix>Wenn diese Klausel angegeben ist, werden nur Schlüssel, die mit denselben Bytes wie eines oder mehrere der angegebenen Präfixe beginnen, in diesen Index aufgenommen. Wenn diese Klausel weggelassen wird, werden alle Schlüssel des richtigen Typs eingeschlossen. Ein Präfix mit der Länge Null würde auch allen Schlüsseln des richtigen Typs entsprechen.

**Feldtypen:**
+ TAG: Ein Tag-Feld ist eine Zeichenfolge, die einen oder mehrere Tag-Werte enthält. 
  + SEPARATOR <sep>(optional): Eines der Zeichen, die zur Abgrenzung einzelner Tags `,.<>{}[]"':;!@#$%^&*()-+=~` verwendet werden. Wenn es weggelassen wird, ist `,` der Standardwert.
  + CASESENSITIVE (optional): Falls vorhanden, wird bei Tag-Vergleichen zwischen Groß- und Kleinschreibung unterschieden. Standardmäßig wird bei Tag-Vergleichen NICHT zwischen Groß- und Kleinschreibung unterschieden.
+ NUMERISCH: Ein numerisches Feld enthält eine Zahl.
+ VEKTOR: Ein Vektorfeld enthält einen Vektor. Derzeit werden zwei Algorithmen zur Vektorindizierung unterstützt: HNSW (Hierarchical Navigable Small World) und FLAT (Brute Force). Jeder Algorithmus hat eine Reihe zusätzlicher Attribute, von denen einige erforderlich und andere optional sind.
  + FLAT: Der Flat-Algorithmus liefert exakte Antworten, hat jedoch eine Laufzeit, die proportional zur Anzahl der indizierten Vektoren ist, und ist daher möglicherweise nicht für große Datensätze geeignet.
    + DIM <number>(erforderlich): Gibt die Anzahl der Dimensionen in einem Vektor an.
    + TYPE FLOAT32 (erforderlich): Datentyp, FLOAT32 wird derzeit nur unterstützt.
    + DISTANCE\$1METRIC [L2 \$1 IP \$1 COSINE] (erforderlich): Gibt den Entfernungsalgorithmus an.
    + <size>INITIAL\$1CAP (optional): Anfängliche Indexgröße.
  + HNSW: Der HNSW-Algorithmus liefert ungefähre Antworten, arbeitet aber wesentlich schneller als FLAT.
    + DIM <number>(erforderlich): Gibt die Anzahl der Dimensionen in einem Vektor an. 
    + TYPE FLOAT32 (erforderlich): Datentyp, FLOAT32 wird derzeit nur unterstützt.
    + DISTANCE\$1METRIC [L2 \$1 IP \$1 COSINE] (erforderlich): Gibt den Entfernungsalgorithmus an.
    + <size>INITIAL\$1CAP (optional): Anfängliche Indexgröße.
    + M <number>(optional): Anzahl der maximal zulässigen ausgehenden Kanten für jeden Knoten im Diagramm in jeder Ebene. Auf Ebene Null beträgt die maximale Anzahl ausgehender Kanten 2\$1M. Der Standardwert ist 16, das Maximum ist 512.
    + EF\$1CONSTRUCTION <number>(optional): Steuert die Anzahl der Vektoren, die bei der Indexkonstruktion untersucht werden. Höhere Werte für diesen Parameter verbessern die Abrufrate auf Kosten längerer Indexerstellungszeiten. Der Standardwert ist 200. Der Höchstwert ist 4096.
    + EF\$1RUNTIME <number>(optional): Steuert die Anzahl der Vektoren, die während eines Abfragevorgangs untersucht werden sollen. Der Standardwert ist 10 und der Höchstwert ist 4096. Sie können diesen Parameterwert für jede Abfrage festlegen, die Sie ausführen. Höhere Werte verlängern die Abfragezeit, verbessern jedoch den Abfrageabruf.

**ANTWORT:** OK oder Fehler.

# FT.SEARCH
<a name="vector-search-commands-ft.search"></a>

Führt eine Suche im angegebenen Index durch. Die Schlüssel, die dem Abfrageausdruck entsprechen, werden zurückgegeben.

```
FT.SEARCH <index-name> <query>
[NOCONTENT]
[RETURN <token_count> (<field-identifier> [AS <alias>])+]
[TIMEOUT timeout] 
[PARAMS <count> <name> <value> [<name> <value>]]
[LIMIT <offset> <count>]
```
+ <index>(erforderlich): Dieser Indexname, den Sie abfragen möchten.
+ <query>(erforderlich): Die Abfragezeichenfolge, Einzelheiten finden Sie unten.
+ NOCONTENT (optional): Falls vorhanden, werden nur die resultierenden Schlüsselnamen zurückgegeben, keine Schlüsselwerte sind enthalten.
+ TIMEOUT <timeout>(optional): Ermöglicht das Festlegen eines Timeout-Werts für den Suchbefehl. Dies muss eine Ganzzahl in Millisekunden sein.
+ <count><name1><value1><name2><value2>PARAMETER... (optional): `count` entspricht der Anzahl der Argumente, d. h. der doppelten Anzahl von Wertenamenpaaren. Einzelheiten zur Verwendung finden Sie in der Abfragezeichenfolge.
+ RÜCKKEHR <count><field1><field2>... (optional): Anzahl ist die Anzahl der Felder, die zurückgegeben werden sollen. Gibt die Felder an, die Sie aus Ihren Dokumenten abrufen möchten, zusammen mit allen Aliasnamen für die zurückgegebenen Werte. Standardmäßig werden alle Felder zurückgegeben, es sei denn, die Option NOCONTENT ist gesetzt. In diesem Fall werden keine Felder zurückgegeben. Wenn count auf 0 gesetzt ist, verhält es sich genauso wie NOCONTENT.
+ LIMIT: <offset><count>: Ermöglicht es Ihnen, einen Teil des Ergebnisses auszuwählen. Die ersten <offset>Schlüssel werden übersprungen und nur ein Maximum an <count>Schlüsseln ist enthalten. Die Standardeinstellung ist LIMIT 0 10, wodurch maximal 10 Schlüssel zurückgegeben werden.
+ 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).
+ DIALEKT: <dialect>(optional): Gibt Ihren Dialekt an. Der einzige unterstützte Dialekt ist 2.

**ANTWORT**

Der Befehl gibt bei Erfolg entweder ein Array oder einen Fehler zurück.

Bei Erfolg steht der erste Eintrag im Antwort-Array für die Anzahl der passenden Schlüssel, gefolgt von einem Array-Eintrag für jeden passenden Schlüssel. Beachten Sie, dass die angegebene `LIMIT` Option nur die Anzahl der zurückgegebenen Schlüssel steuert und den Wert des ersten Eintrags nicht beeinflusst.

Wenn `NOCONTENT` angegeben, enthält jeder Eintrag in der Antwort nur den passenden Schlüsselnamen. Andernfalls enthält jeder Eintrag den passenden Schlüsselnamen, gefolgt von einem Array der zurückgegebenen Felder. Die Ergebnisfelder für einen Schlüssel bestehen aus einer Reihe von name/value Paaren. Das erste name/value Paar steht für die berechnete Entfernung. Der Name dieses Paares wird aus dem Vektorfeldnamen gebildet, dem „\$1\$1“ vorangestellt und „\$1score“ angehängt wird. Der Wert entspricht der berechneten Entfernung. Die verbleibenden name/value Paare sind die Elemente und Werte des Schlüssels, der durch die Klausel gesteuert wird. `RETURN` 

Die Abfragezeichenfolge entspricht dieser Syntax:

```
<filtering>=>[ KNN <K> @<vector_field_name> $<vector_parameter_name> <query-modifiers> ]
```

Wobei Folgendes gilt:
+ <filtering>: Ist entweder ein\$1 oder ein Filterausdruck. Ein \$1 bedeutet, dass keine Filterung erfolgt und somit alle Vektoren innerhalb des Index durchsucht werden. Ein Filterausdruck kann angegeben werden, um eine Teilmenge der zu durchsuchenden Vektoren zu bezeichnen.
+ <vector\$1field\$1name>: Der Name eines Vektorfeldes innerhalb des angegebenen Index.
+ <K>: Die Anzahl der Vektoren mit den nächsten Nachbarn, die zurückgegeben werden sollen.
+ <vector\$1parameter\$1name>: Ein PARAM-Name, dessen entsprechender Wert den Abfragevektor für den KNN-Algorithmus bereitstellt. Beachten Sie, dass dieser Parameter als binäre 32-Bit-Gleitkommazahl nach IEEE 754 im Little-Endian-Format codiert werden muss.
+ <query-modifiers>: (Optional) Eine Liste von keyword/value Paaren, die diese spezielle KNN-Suche modifizieren. Derzeit werden zwei Schlüsselwörter unterstützt:
  + EF\$1RUNTIME: Dieses Schlüsselwort wird von einem Integer-Wert begleitet, der den Standardwert von EF\$1RUNTIME überschreibt, der bei der Indexerstellung angegeben wurde.
  + AS: Dieses Schlüsselwort wird von einem Zeichenkettenwert begleitet, der im Ergebnis zum Namen des Bewertungsfeldes wird und den Standardalgorithmus zur Generierung von Score-Feldnamen überschreibt.

**Ausdruck filtern**

Ein Filterausdruck besteht aus einer logischen Kombination von Tag-Suchoperatoren und numerischen Suchoperatoren, die in Klammern stehen.

**Markierung**

Der Tag-Suchoperator wird mit einer oder mehreren Zeichenfolgen angegeben, die durch das Zeichen \$1 getrennt sind. Ein Schlüssel entspricht dem Tag-Suchoperator, wenn das angegebene Feld eine der angegebenen Zeichenketten enthält.

```
@<field_name>:{<tag>}
or
@<field_name>:{<tag1> | <tag2>}
or
@<field_name>:{<tag1> | <tag2> | ...}
```

Die folgende Abfrage gibt beispielsweise Dokumente mit blauer ODER schwarzer ODER grüner Farbe zurück.

`@color:{blue | black | green}`

Als weiteres Beispiel gibt die folgende Abfrage Dokumente zurück, die „Hello World“ oder „Hello Universe“ enthalten.

`@description:{hello world | hello universe}`

**Numerischer Bereich**

Der numerische Bereichsoperator ermöglicht das Filtern von Abfragen, sodass nur Werte zurückgegeben werden, die zwischen einem bestimmten Start- und Endwert liegen. Sowohl inklusive als auch exklusive Bereichsabfragen werden unterstützt. Für einfache relationale Vergleiche kann \$1inf, -inf mit einer Bereichsabfrage verwendet werden. Die Syntax für einen Bereichssuchoperator lautet:

```
@<field_name>:[ [(] <bound> [(] <bound>]
```

... wobei <bound>entweder eine Zahl oder \$1inf oder -inf ist. Grenzen ohne eine führende offene Klammer sind inklusiv, wohingegen Grenzen mit der führenden offenen Klammer exklusiv sind. 

Verwenden Sie die folgende Tabelle als Leitfaden für die Zuordnung mathematischer Ausdrücke zu Filterabfragen:

```
min <= field <= max         @field:[min max]
min < field <= max          @field:[(min max]
min <= field < max            @field:[min (max]
min < field < max            @field:[(min (max]
field >= min                @field:[min +inf]
field > min                    @field:[(min +inf]
field <= max                @field:[-inf max]
field < max                    @field:[-inf (max]
field == val                @field:[val val]
```

**Logische Operatoren**

Mehrere Tags und numerische Suchoperatoren können verwendet werden, um komplexe Abfragen mithilfe logischer Operatoren zu erstellen.

**Logisches UND**

Um ein logisches UND festzulegen, verwenden Sie ein Leerzeichen zwischen den Prädikaten. Beispiel:

`query1 query2 query3`

**Logisches ODER**

Um ein logisches ODER festzulegen, verwenden Sie ein Leerzeichen zwischen den Prädikaten. Beispiel:

`query1 | query2 | query3`

**Logische Negation**

Jede Abfrage kann negiert werden, indem das `-` Zeichen vor jeder Abfrage vorangestellt wird. Negative Abfragen geben alle Einträge zurück, die nicht mit der Abfrage übereinstimmen. Dies schließt auch Schlüssel ein, die das Feld nicht enthalten.

Eine negative Abfrage auf @genre: \$1comedy\$1 gibt beispielsweise alle Bücher zurück, die keine Komödie sind UND alle Bücher, die kein Genrefeld haben.

Die folgende Abfrage gibt alle Bücher des Genres „Komödie“ zurück, die nicht zwischen 2015 und 2024 veröffentlicht wurden oder die kein Jahresfeld haben: @genre: [Komödie] - @year: [2015 2024]

Rangfolge der Operatoren

Es gelten die typischen Regeln für die Rangfolge von Operatoren, d. h. logisches NEGATE hat die höchste Priorität, gefolgt von logischem UND dann logisches ODER mit der niedrigsten Priorität. Klammern können verwendet werden, um die Standardregeln für die Rangfolge außer Kraft zu setzen.

*Beispiele für die Kombination logischer Operatoren*

Logische Operatoren können zu komplexen Filterausdrücken kombiniert werden.

Die folgende Abfrage gibt alle Bücher mit den Genres „Komödie“ oder „Horror“ (AND) zurück, die zwischen 2015 und 2024 veröffentlicht wurden: `@genre:[comedy|horror] @year:[2015 2024]`

Die folgende Abfrage gibt alle Bücher mit den Genres „Komödie“ oder „Horror“ (OR) zurück, die zwischen 2015 und 2024 veröffentlicht wurden: `@genre:[comedy|horror] | @year:[2015 2024]`

Die folgende Abfrage gibt alle Bücher zurück, die entweder kein Genrefeld haben oder deren Genrefeld nicht „Komödie“ entspricht und die zwischen 2015 und 2024 veröffentlicht wurden: `-@genre:[comedy] @year:[2015 2024]`

# FT.DROPINDEX
<a name="vector-search-commands-ft.dropindex"></a>

**Syntax**

```
FT.DROPINDEX <index-name>
```

Der angegebene Index wird gelöscht. Gibt OK oder einen Fehler zurück, wenn dieser Index nicht existiert.
+ <index-name>(erforderlich): Der Name des zu löschenden Indexes.

# FT.INFO
<a name="vector-search-commands-ft.info"></a>

**Syntax**

```
FT.INFO <index-name>
```

Die Vektorsuche erweitert den Befehl [FT.INFO](https://valkey.io/commands/info/) um mehrere zusätzliche Abschnitte mit Statistiken und Zählern. Eine Anfrage zum Abrufen des Abschnitts SEARCH ruft alle der folgenden Statistiken ab:


| Tastenname | Werttyp | Description | 
| --- | --- | --- | 
| index\$1name | Zeichenfolge | Name des Indexes | 
| index\$1options | Zeichenfolge | Reserved Instances. Derzeit auf „0" gesetzt | 
| index\$1definition | Array | Im Folgenden finden Sie die Definition dieser Array-Elemente. | 
| Attribute | Array von Attributinformationen | Ein Element in diesem Array für jedes definierte Attribut. Die Definition der Attributinformationen finden Sie weiter unten. | 
| num\$1docs | Ganzzahl | Anzahl der aktuell im Index enthaltenen Schlüssel | 
| num\$1terms | Ganzzahl | Reserved Instances. Derzeit auf „0" gesetzt. | 
| record\$1count | Ganzzahl | Die Summe des Felds „Größe“ für jedes Attribut. | 
| hash\$1indexing\$1failures | Ganzzahl | Gibt an, wie oft ein Attribut nicht in den deklarierten Attributtyp konvertiert werden konnte. Trotz des Namens gilt dies auch für JSON-Schlüssel. | 
| backfill\$1in\$1progress | Ganzzahl | Wenn gerade ein Backfill im Gange ist, wird dies eine '1' sein, andernfalls ist es eine '0' | 
| backfill\$1percent\$1complete | float | Schätzung des Abschlusses des Füllstands, eine Bruchzahl im Bereich [0.. 1] | 
| mutation\$1queue\$1size | Ganzzahl | Anzahl der Schlüssel, die darauf warten, den Index zu aktualisieren. | 
| recent\$1mutations\$1queue\$1delay | Ganzzahl | Schätzung der Verzögerung (in Sekunden) der Indexaktualisierung. 0, wenn keine Aktualisierungen im Gange sind. | 
| state | Zeichenfolge | Backfill-Status: „Bereit“ gibt an, dass das Auffüllen erfolgreich abgeschlossen wurde. „backfill\$1in\$1progress“ gibt an, dass das Auffüllen fortgesetzt wird. „backfill\$1paused\$1by\$1oom“ bedeutet, dass das Backfilling aufgrund eines unzureichenden Speicherzustands unterbrochen wurde. Sobald der Speichermangel behoben ist, wird der Backillvorgang fortgesetzt. | 

Die Struktur index\$1definition ist ein Array von key/value Paaren, die wie folgt definiert sind:


| Tastenname | Werttyp | Description | 
| --- | --- | --- | 
| key\$1type | Zeichenfolge | Entweder die Zeichenfolge 'JSON' oder die Zeichenfolge 'HASH' | 
| prefixes | Array | Jedes Element im Array ist ein definiertes Präfix für den Index. Wenn bei der Erstellung des Indexes keine Präfixe angegeben wurden, hat dieses Array 0 Einträge. | 
| default\$1score | Zeichenfolge | Reserved Instances. Derzeit auf „1" eingestellt | 

Attributinformationen: Die Attributinformationen sind typspezifisch.

Numerische Attribute:


| Key (Schlüssel) | Werttyp | Description | 
| --- | --- | --- | 
| Bezeichner | Zeichenfolge | Position des Attributs innerhalb eines Schlüssels. Hash-Mitgliedsname oder JSON-Pfad | 
| alias | Zeichenfolge | Name des Attributs, das in Abfragebeschreibungen verwendet wird. | 
| type | Zeichenfolge | Die Zeichenfolge „NUMERIC“ | 
| size | Ganzzahl | Die Anzahl der Schlüssel mit gültigen numerischen Werten in diesem Attribut. | 

Tag-Attribute:


| Tastenname | Werttyp | Description | 
| --- | --- | --- | 
| Bezeichner | Zeichenfolge | Position des Attributs innerhalb eines Schlüssels. Hash-Mitgliedsname oder JSON-Pfad | 
| alias | Zeichenfolge | Name des Attributs, das in Abfragebeschreibungen verwendet wird. | 
| type | Zeichenfolge | Die Zeichenfolge „TAG“ | 
| SEPARATOR | character | Das Trennzeichen, das bei der Erstellung des Indexes definiert wurde | 
| GROSS- UND KLEINSCHREIBUNG BEACHTEN | – | Diesem Schlüssel ist kein Wert zugeordnet. Es ist nur vorhanden, wenn das Attribut mit dieser Option erstellt wurde. | 
| size | Ganzzahl | Die Anzahl der Schlüssel mit gültigen Tag-Werten in diesem Attribut | 

Vektor-Attribute:


| Tastenname | Werttyp | Description | 
| --- | --- | --- | 
| Bezeichner | Zeichenfolge | Position des Attributs innerhalb eines Schlüssels. Hash-Mitgliedsname oder JSON-Pfad | 
| alias | Zeichenfolge | Name des Attributs, das in Abfragebeschreibungen verwendet wird. | 
| type | Zeichenfolge | Die Zeichenfolge „VECTOR“ | 
| index | character | Eine weitere Beschreibung des Vektorindex finden Sie unten. | 

Beschreibung des Vektorindex:


| Tastenname | Werttyp | Description | 
| --- | --- | --- | 
| Kapazität | Zeichenfolge | Aktuelle Kapazität des Index | 
| dimensions | Zeichenfolge | Anzahl der Elemente in jedem Vektor | 
| distance\$1metric | Zeichenfolge | Einer von „COSINE“, „L2" oder „IP“ | 
| size | Array  | Beschreibung des Vektorindex, siehe unten. | 
| data\$1type | Zeichenfolge | Deklarierter Datentyp. Derzeit wird nur FLOAT32 "" unterstützt. | 
| Algorithmus | Array  | Weitere Beschreibung des Vektorsuchalgorithmus. | 

FLAT-Vektor-Suchalgorithmus Beschreibung:


| Tastenname | Werttyp | Description | 
| --- | --- | --- | 
| name | Zeichenfolge | Name des Algorithmus: FLAT | 
| block\$1size | number | Größe eines Blocks des FLAT-Index. | 

Beschreibung des HNSW-Vektorindexes:


| Tastenname | Werttyp | Description | 
| --- | --- | --- | 
| name | Zeichenfolge | Name des Algorithmus: HNSW | 
| m | number | Der Parameter „M“ für HNSW | 
| ef\$1construction | number | Der Parameter „ef\$1construction“ für HNSW | 
| ef\$1runtime | number | Der Parameter „ef\$1runtime“ für HNSW. | 

# FT. \$1LISTE
<a name="vector-search-commands-ft.list"></a>

Listet alle Indizes auf.

**Syntax**

```
FT._LIST 
```

Gibt ein Array von Zeichenketten zurück, die den Namen des aktuell definierten Indexes entsprechen.