Überblick über die Vektorsuche - Amazon ElastiCache
Indizes und der Valkey OSS-KeyspaceIndex-FeldtypenVektor-Index-AlgorithmenSicherheit bei der Vektorsuche

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.

Überblick über die Vektorsuche

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.SEARCHfü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.

Indizes und der Valkey OSS-Keyspace

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_status“ zurück.

Index-Feldtypen

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 erwartetHASH, 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

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_Construction bestimmt, wie viele mögliche Verbindungen bei der Indexerstellung ausgewertet werden. Ein höherer Wert von EF_Construction, 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_Construction, 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_Runtime auf einen hohen Wert eingestellt ist.

Schließlich bestimmt EF_Runtime 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_Runtime macht Abfragen schneller und einfacher, allerdings mit geringerem Abruf. Im Gegensatz zu M oder EF_Construction 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

Die Sicherheitsmechanismen von Valkey ACL (Access Control Lists) 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.