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.
# Suchfunktionen und Einschränkungen
## Suchen Sie nach Verfügbarkeit
ElastiCache Valkey Version 9.0 und höher bietet Unterstützung für reine Non-Vektor-, Vektor- und Hybrid-Workloads, einschließlich numerischer, Tag-Suchen (exakt übereinstimmend) Full-text, Vektorsuchen und Aggregationen auf knotenbasierten Clustern in allen Regionen ohne zusätzliche Kosten. AWS
ElastiCache Valkey Version 8.2 bietet Unterstützung für Vector Search auf knotenbasierten Clustern in allen Regionen ohne zusätzliche Kosten. AWS
[Sie können die Suche 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 die oben genannten Valkey-Versionen aktualisieren.](VersionManagement.HowTo.md)
Die Suche ist derzeit für alle ElastiCache Instance-Typen mit Ausnahme von Knoten mit Daten-Tiering verfügbar. Die Verwendung der Suche 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
Die folgende Tabelle zeigt Grenzwerte für verschiedene Suchbegriffe:
**Beschränkungen für die Suche**
| Item | Maximalwert (9,0\+) | Maximalwert (8,2) |
| --- | --- | --- |
| Anzahl der Dimensionen in einem Vektor | 32768 | 32768 |
| Anzahl der Indizes, die erstellt werden können | 1000 | 10 |
| Anzahl der Felder in einem Index | 1000 | 50 |
| FT.SEARCH TIMEOUT-Klausel (Millisekunden) | 60000 | 60000 |
| Maximal zulässige Anzahl von Präfixen pro Index | 16 | 16 |
| Maximale Länge eines Tag-Felds | 10000 | 10000 |
| Maximale Länge eines numerischen Feldes | 256 | 256 |
| HNSW M-Parameter | 2000000 | 2000000 |
| HNSW EF\_KONSTRUKTIONSPARAMETER | 1000000 | 4096 |
| HNSW EF\_RUNTIME-Parameter | 1000000 | 4096 |
| Anzahl der Begriffe, die in einer Abfragezeichenfolge in Befehlen verwendet werden dürfen FT.SEARCH/FT.AGGREGATE | 1000 | 16 |
| Anzahl der pro Index zulässigen Textattribute | 64 | N/A |
| Maximale Anzahl von Texterweiterungen bei der Suche nach Präfix-, Suffix-, Fuzzy- und Stammbegriffen | 200 | N/A |
## Betriebsbedingte Einschränkungen
### Persistenz und Backfilling von Indizes
Weitere Informationen dazu finden Sie unter [Erstellung und Vervollständigung des Valkey-Suchindexes](https://valkey.io/topics/search/#index-creation-and-backfill).
### Grenzen der Skalierung
In ElastiCache Valkey Version 9.0 kann sich bei Skalierungsereignissen der Schreib-RPS für die Dauer des Ereignisses verringern. In ElastiCache Valkey, Version 8.2, kann es bei Skalierungsereignissen dazu kommen, dass der Index während der Datenmigration wieder aufgefüllt wird, was zu einem geringeren Abruf von Suchanfragen führt.
### Snapshot import/export und Live-Migration
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
Ähnlich wie bei Valkey-OSS-Schreibvorgängen unterliegt ein Index-Backfill Einschränkungen bei zu wenig Arbeitsspeicher. 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
Die Befehle `FT.CREATE` und `FT.DROPINDEX` können nicht in einem Transaktionskontext ausgeführt werden, d. h. nicht innerhalb eines `MULTI/EXEC` Blocks oder innerhalb eines LUA- oder FUNCTION-Skripts. Darüber hinaus können die `FT.AGGREGATE` Befehle `FT.SEARCH` und nicht in einem Transaktionskontext in einem ElastiCache Valkey-Cluster ausgeführt werden, der im Cluster-Modus arbeitet.
## Sicherheit in der Suche
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.