Häufig gestellte Fragen zu Amazon MemoryDB

MemoryDB Multi-Region ist eine vollständig verwaltete, active-active, regionsübergreifende Datenbank, mit der Kunden Anwendungen mit einer Verfügbarkeit von bis zu 99,999 % mit Lese- und einstelligen Millisekunden-Schreiblatenzen erstellen können. Es bietet Datenredundanz über mehrere AWS-Regionen hinweg, sodass Sie die Verfügbarkeit und Stabilität Ihrer multiregionalen Anwendungen verbessern können, selbst wenn die Verarbeitung einer Anwendung in einer Region unterbrochen wird und keine Verbindung zu ihrem MemoryDB-Endpunkt hergestellt werden kann. MemoryDB Multi-Region bietet eine Active-Active-Replikation, sodass Sie Lese- und Schreibvorgänge lokal aus den Regionen, die Ihren Kunden am nächsten sind, bereitstellen können, mit einer Leselatenz im Mikrosekunden- und einer Schreiblatenz im einstelligen Millisekundenbereich. Es repliziert Daten asynchron zwischen Regionen und Daten werden in der Regel innerhalb einer Sekunde weitergegeben. MemoryDB Multi-Region löst automatisch Aktualisierungskonflikte und korrigiert Datendivergenzen, sodass Sie sich auf Ihre Anwendung konzentrieren können.

Sie sollten MemoryDB Multi-Region verwenden, wenn Sie Anwendungen entwickeln möchten, die ein Höchstmaß an Verfügbarkeit, erhöhte Stabilität und verbesserte Geschäftskontinuität benötigen. MemoryDB Multi-Region kann auch verwendet werden, wenn Sie Anwendungen mit mehreren Regionen erstellen und ausführen möchten, die überall auf der Welt schnelle Reaktionszeiten erfordern.

Bei Verwendung von MemoryDB Multi-Region repliziert MemoryDB Daten über regionale Cluster in einer Konfiguration, die als Multi-Region-Cluster bezeichnet wird. Wenn Daten in einen beliebigen regionalen Cluster innerhalb des Clusters mit mehreren Regionen geschrieben werden, repliziert MemoryDB diese Daten automatisch und asynchron auf alle anderen regionalen Cluster, normalerweise innerhalb einer Sekunde, ohne die Leistung Ihrer Anwendung zu beeinträchtigen. MemoryDB Multi-Region löst automatisch Aktualisierungskonflikte und korrigiert Datendivergenzen. Die Konfliktlösung wird vollständig verwaltet und erfolgt im Hintergrund, ohne dass die Verfügbarkeit der Anwendung beeinträchtigt wird.

Um mit MemoryDB Multi-Region zu beginnen, erstellen Sie mithilfe der AWS-Konsole, des AWS-SDK oder der CLI einen neuen Cluster mit mehreren Regionen und einen regionalen Cluster in einer Ihrer gewünschten AWS-Regionen. Sobald der erste regionale Cluster erstellt wurde, können Sie bis zu vier weitere Regionen zur ihrem multiregionalen Cluster hinzufügen. Wenn Daten in einen regionalen Cluster geschrieben werden, repliziert MemoryDB Multi-Region diese Daten automatisch auf alle anderen regionalen Cluster innerhalb des Clusters mit mehreren Regionen, normalerweise innerhalb einer Sekunde. Wenn Sie MemoryDB heute verwenden, können Sie einen Snapshot Ihres Clusters erstellen und ihn verwenden, um einen neuen Cluster mit mehreren Regionen und einen regionalen Cluster zu starten.  

Sie können einem MemoryDB-Cluster mit mehreren Regionen neue regionale Cluster hinzufügen, indem Sie regionale Cluster in den jeweiligen AWS-Regionen erstellen. Sie können jedoch keinen vorhandenen MemoryDB-Cluster zu einem vorhandenen MemoryDB-Cluster mit mehreren Regionen hinzufügen. Sie können nur einen neuen regionalen Cluster erstellen oder einen vorhandenen regionalen Cluster aus einem MemoryDB-Multi-Region-Cluster entfernen. Wenn Sie einen regionalen Cluster entfernen, löscht MemoryDB Multi-Region den Cluster in dieser bestimmten Region, während der MemoryDB-Multi-Region-Cluster erhalten bleibt. Kunden können sich später dafür entscheiden, weitere regionale Cluster innerhalb desselben MemoryDB-Multi-Region-Clusters hinzuzufügen.

MemoryDB Multi-Region sorgt für letztendliche Konsistenz, da es eine asynchrone Replikation durchführt, wodurch die speicherinternen Geschwindigkeiten erhalten bleiben. Alle Aktualisierungen, die an einem Schlüssel in einem der MemoryDB-Multi-Region-Cluster vorgenommen werden, werden asynchron an andere regionale Cluster innerhalb des MemoryDB-Multi-Region-Clusters weitergegeben, normalerweise in weniger als einer Sekunde.

MemoryDB Multi-Region verwendet den Conflict-Free-Replicated-Data-Type (CRDT), um widersprüchliche gleichzeitige Schreibvorgänge abzugleichen. CRDT ist eine Datenstruktur, die unabhängig und gleichzeitig ohne Koordination aktualisiert werden kann. Der Write-Writer-Konflikt wird auf jedem Replikat unabhängig zusammengeführt, sodass es letztendlich konsistent ist.

Wenn eine Region isoliert oder herabgestuft wird, verfolgt MemoryDB Multi-Region alle ausgeführten Schreibvorgänge, die aber noch nicht an alle regionalen Cluster weitergegeben wurden. Wenn die Region wieder online ist, leitet MemoryDB Multi-Region wieder alle ausstehenden Schreibvorgänge aus dieser Region an die regionalen Cluster in anderen Regionen weiter. Außerdem werden Schreibvorgänge von anderen regionalen Clustern an die Region weitergegeben, die jetzt wieder online ist. MemoryDB Multi-Region verbreitet irgendwann alle zuvor erfolgreichen Schreibvorgänge, unabhängig davon, wie lange die Region isoliert ist. Konflikte können auftreten, wenn Ihre Anwendung denselben Schlüssel in verschiedenen Regionen ungefähr zur gleichen Zeit aktualisiert. MemoryDB Multi-Region verwendet den Conflict-Free-Replicated-Data-Type-(CRDT)-Abgleich zwischen gleichzeitigen Aktualisierungen. Die Konfliktlösung wird vollständig verwaltet und erfolgt im Hintergrund, ohne dass die Verfügbarkeit der Anwendung beeinträchtigt wird.

Der Durchsatz und die Latenz von MemoryDB variieren je nach Knotentyp, Nutzlastgröße und Anzahl der Client-Verbindungen. MemoryDB bietet eine Leselatenz im Mikrosekundenbereich, eine einstellige Millisekunden-Schreiblatenz und eine Lese-nach-Schreib-Latenz auf dem primären Knoten für einen Cluster-Shard. MemoryDB kann bis zu 390 000 Lese- und 100 000 Schreibanforderungen pro Sekunde sowie bis zu 1,3 GB/s Lese- und 100 MB/s Schreibdurchsatz pro Knoten unterstützen (basierend auf internen Tests mit Nur-Lese- und Schreib-Workloads). Ein MemoryDB-Cluster teilt Daten über einen oder mehrere Knoten hinweg, sodass Sie Ihrem Cluster weitere Shards oder Replikate hinzufügen können, um den Gesamtdurchsatz zu erhöhen.

MemoryDB speichert Ihren gesamten Datensatz im Arbeitsspeicher und verwendet ein verteiltes Multi-AZ-Transaktionsprotokoll, um die Haltbarkeit, Konsistenz und Wiederherstellbarkeit der Daten zu gewährleisten. Durch das Speichern von Daten auf mehreren AZs kann MemoryDB die Datenbank schnell wiederherstellen und neu starten. Da MemoryDB die Daten auch im Speicher speichert, kann es eine ultraschnelle Leistung und einen hohen Durchsatz bieten.

MemoryDB nutzt ein verteiltes Transaktionsprotokoll, um Daten dauerhaft zu speichern. Durch das Speichern von Daten auf mehreren AZs kann MemoryDB die Datenbank schnell wiederherstellen und neu starten. Außerdem bietet MemoryDB eine gewisse Konsistenz für Replikatknoten und konsistente Lesevorgänge auf Primärknoten.

Valkey und Redis OSS enthalten ein optionales Feature für Append-Only-Dateien (AOF), das Daten in einer Datei auf der Festplatte eines primären Knotens speichert, um die Haltbarkeit zu erhöhen. Da AOF Daten jedoch lokal auf primären Knoten in einer einzigen Availability Zone speichert, besteht das Risiko eines Datenverlusts. Außerdem besteht bei einem Knotenausfall das Risiko von Konsistenzproblemen mit Replikaten.

Ja, MemoryDB unterstützt Hochverfügbarkeit. Sie können einen MemoryDB-Cluster mit Multi-AZ-Verfügbarkeit mit bis zu 5 Replikaten in verschiedenen AZs erstellen. Wenn ein Ausfall auf einem primären Knoten auftritt, führt MemoryDB automatisch ein Failover durch und stuft eines der Replikate als neuen primären Knoten hoch und leitet den Schreibverkehr an diesen Knoten weiter. Darüber hinaus verwendet MemoryDB ein verteiltes Transaktionsprotokoll, um sicherzustellen, dass die Daten auf den Replikaten auch bei einem Ausfall des Primärknotens auf dem neuesten Stand gehalten werden. Ein Failover erfolgt in der Regel in weniger als 20 Sekunden bei ungeplanten Ausfällen und in der Regel in weniger als 200 Millisekunden bei geplanten Ausfällen.

MemoryDB verwendet ein verteiltes Transaktionslog, um Daten, die während der Datenbankwiederherstellung, des Neustarts, des Failovers und der eventuellen Konsistenz zwischen Primär- und Replikaten in Ihre Datenbank geschrieben wurden, dauerhaft zu speichern.

Valkey und Redis OSS ermöglichen Schreibvorgänge und strikt konsistente Lesevorgänge auf dem Primärknoten jedes Shards und letzendlich konsistente Lesevorgänge von Lese-Replikaten. Diese Konsistenzeigenschaften sind nicht garantiert, wenn ein primärer Knoten ausfällt, da Schreibvorgänge bei einem Failover verloren gehen und somit das Konsistenzmodell verletzen können.

Das Konsistenzmodell von MemoryDB ähnelt Valkey und Redis OSS. In MemoryDB gehen bei Failovers jedoch keine Daten verloren, sodass Clients ihre Schreibvorgänge unabhängig von Knotenausfällen von Primärdateien lesen können. Nur Daten, die erfolgreich im Multi-AZ-Transaktionsprotokoll gespeichert wurden, sind sichtbar. Die Replikatknoten sind letztendlich immer noch konsistent, und die Lag-Metriken werden auf Amazon CloudWatch veröffentlicht.

Mit MemoryDB Version 7.0 für Redis OSS haben wir verbessertes E/A-Multiplexing eingeführt, das zusätzliche Verbesserungen bei Durchsatz und Latenz in großem Maßstab bietet. MemoryDB Version 7.2 für Valkey unterstützt auch verbessertes E/A-Multiplexing. Verbessertes E/A-Multiplexing ist ideal für durchsatzgebundene Workloads mit mehreren Client-Verbindungen und seine Vorteile skalieren mit dem Grad der Workload-Parallelität. Wenn Sie beispielsweise den r6g.4xlarge-Knoten verwenden und 5 200 gleichzeitige Clients ausführen, können Sie im Vergleich zu MemoryDB Version 6 für Redis OSS einen um bis zu 46 % höheren Durchsatz (Lese- und Schreibvorgänge pro Sekunde) und eine um bis zu 21 % geringere P99-Latenz erzielen. Bei diesen Arten von Workloads kann die Netzwerk-IO-Verarbeitung eines Knotens zu einem begrenzenden Faktor für die Skalierbarkeit werden. Mit verbessertem E/A-Multiplexing leitet jeder dedizierte Netzwerk-E/A-Thread Befehle von mehreren Clients in die MemoryDB-Engine weiter und nutzt dabei die Fähigkeit der Engine, Befehle effizient in Stacks zu verarbeiten.

Weitere Informationen finden Sie in der Dokumentation.

Um Daten in Ihren MemoryDB-Cluster zu schreiben und daraus zu lesen, stellen Sie mithilfe eines der unterstützten Valkey- oder Redis-OSS-Clients eine Verbindung zu Ihrem Cluster her. Eine Liste der unterstützten Valkey- oder Redis-OSS-Clients finden Sie in der Valkey- oder Redis-OSS-Dokumentation. Anweisungen zum Herstellen einer Verbindung zu Ihrem MemoryDB-Cluster mithilfe eines Valkey- oder Redis-OSS-Clients finden Sie in der MemoryDB-Dokumentation. Valkey funktioniert mit vorhandenen Redis-OSS-Clients, sodass Sie beim Wechsel von Redis OSS zu Valkey die Clients nicht wechseln müssen.

Sie erstellen einen MemoryDB-Cluster mit bis zu 500 Knoten. Dies ergibt eine maximale Speicherkapazität von ~100 TB, vorausgesetzt, Sie haben 250 primäre Knoten mit jeweils einem Replikat für hohe Verfügbarkeit (insgesamt 500 Knoten).

Ja, Sie können die Größe Ihres MemoryDB-Clusters horizontal und vertikal ändern. Sie können Ihren Cluster horizontal skalieren, indem Sie Knoten hinzufügen oder entfernen. Sie können sich dafür entscheiden, Shards hinzuzufügen, um Ihr Dataset auf mehrere Shards zu verteilen, und Sie können jedem Shard zusätzliche Replikatknoten hinzufügen, um die Verfügbarkeit und den Lesedurchsatz zu erhöhen. Sie können auch Shards und Replikate entfernen, um Ihren Cluster zu skalieren. Darüber hinaus können Sie Ihren Cluster vertikal skalieren, indem Sie Ihren Knotentyp ändern, wodurch sich Ihre Speicher- und CPU-Ressourcen pro Knoten ändern. Während der horizontalen und vertikalen Größenänderung bleibt Ihr Cluster weiterhin online und verarbeitet Lese- und Schreibanforderungen.

MemoryDB erleichtert die Wartung und Aktualisierung Ihres Clusters und bietet zwei verschiedene Prozesse für die Cluster-Wartung. Erstens patcht MemoryDB Ihren Cluster bei einigen obligatorischen Updates automatisch während der von Ihnen angegebenen Wartungsfenster. Zweitens verwendet MemoryDB für einige Updates Service-Updates, die Sie jederzeit oder nach einem Zeitplan für ein zukünftiges Wartungsfenster anwenden können. Einige Service-Updates werden nach einem bestimmten Datum automatisch in einem Wartungsfenster eingeplant. Cluster-Updates tragen dazu bei, die Sicherheit, Zuverlässigkeit und Betriebsleistung Ihrer Cluster zu verbessern. Ihr Cluster bleibt weiterhin online und verarbeitet Lese- und Schreibanforderungen. Weitere Informationen zur Clusterwartung finden Sie in der MemoryDB-Dokumentation.

Ja, Sie erstellen Snapshots, um die Daten und Metadaten Ihres MemoryDB-Clusters zu sichern. Sie können einen Snapshot manuell erstellen oder den automatisierten Snapshot-Planer von MemoryDB verwenden, um jeden Tag zu einer von Ihnen angegebenen Zeit einen neuen Snapshot zu erstellen. Sie können wählen, ob Sie Ihren Snapshot bis zu 35 Tage nach seiner Erstellung und MemoryDB aufbewahren möchten. Diese Snapshots werden in Amazon S3 gespeichert, das für eine Haltbarkeit von 99,999999999 % (11 Neunen) ausgelegt ist. Sie können sich auch dafür entscheiden, einen endgültigen Snapshot Ihres Clusters zu erstellen, wenn Sie den Cluster löschen. Darüber hinaus können Sie MemoryDB-Snapshots aus dem Service in Ihren Amazon-S3-Bucket exportieren. Weitere Informationen finden Sie in der MemoryDB-Dokumentation.

Ja, Sie können Ihren MemoryDB-Cluster aus einem Snapshot wiederherstellen, wenn Sie einen neuen MemoryDB-Cluster erstellen.

Ja, Sie können Ihren MemoryDB-Cluster aus einer Valkey- oder Redis-OSS-RDB-Datei wiederherstellen. Sie können die RDB-Datei angeben, aus der wiederhergestellt werden soll, wenn Sie einen neuen MemoryDB-Cluster erstellen.

Ja, Sie können Daten von ElastiCache zu MemoryDB migrieren. Erstellen Sie zunächst einen Snapshot Ihres ElastiCache-Clusters und exportieren Sie ihn in Ihren S3-Bucket. Erstellen Sie als Nächstes einen neuen MemoryDB-Cluster und geben Sie das Backup an, aus dem wiederhergestellt werden soll. MemoryDB erstellt einen neuen Cluster mit den Daten und Valkey- oder Redis-OSS-Metadaten aus dem Snapshot. Weitere Informationen zur Migration von Daten von ElastiCache zu MemoryDB finden Sie in der MemoryDB-Dokumentation.

Ja, MemoryDB bietet Betriebs- und Leistungsmetriken für Ihren Cluster. MemoryDB hat über 30 CloudWatch-Metriken, und Sie können diese Metriken in der MemoryDB-Konsole anzeigen. Weitere Informationen zu CloudWatch-Metriken und MemoryDB finden Sie in der MemoryDB-Dokumentation.

Ja, MemoryDB unterstützt die Verschlüsselung Ihrer Daten sowohl im Ruhezustand als auch während der Übertragung. Für die Verschlüsselung im Ruhezustand können Sie vom Kunden verwaltete Schlüssel (CMK) von AWS Key Management Service oder einen von MemoryDB bereitgestellten Schlüssel verwenden. Mit Graviton2-Instances für Ihren MemoryDB-Cluster werden Ihre Daten im Speicher mithilfe der ständig aktiven 256-Bit-DRAM-Verschlüsselung verschlüsselt.

MemoryDB verwendet Zugriffssteuerungslisten (ACLs), um sowohl die Authentifizierung als auch die Autorisierung für Ihren Cluster zu steuern. Mit ACLs können Sie unterschiedliche Berechtigungen für verschiedene Benutzer im selben Cluster festlegen. Eine ACL ist eine Sammlung von einem oder mehreren Benutzern. Jeder Benutzer verfügt über ein Passwort und eine Zugriffszeichenfolge, mit denen der Zugriff auf Befehle und Daten autorisiert wird. Weitere Informationen zu ACLs in MemoryDB finden Sie in der MemoryDB-Dokumentation.

Ja, alle MemoryDB-Cluster müssen in einer VPC gestartet werden.

Wir werden weiterhin mehr Compliance-Zertifizierungen unterstützen. Die neuesten Informationen zur Compliance-Bereitschaft finden Sie hier.

Ja. Zum Abrufen eines Verlaufs aller Amazon-MemoryDB-API-Aufrufe, die für Ihr Konto erfolgt sind, aktivieren Sie CloudTrail in der AWS Management Console. Weitere Informationen finden Sie auf der Startseite von CloudTrail.

Daten-Tiering für Amazon MemoryDB ist eine neue Preis-/Leistungsoption für MemoryDB, die Daten, auf die seltener zugegriffen wird, automatisch vom Speicher auf leistungsstarke, lokal angeschlossene Solid-State-Laufwerke (SSD) verschiebt. Daten-Tiering erhöht die Kapazität, vereinfacht das Clustermanagement und verbessert die Gesamtbetriebskosten (TCO) für MemoryDB.

Sie sollten Daten-Tiering verwenden, wenn Sie eine einfachere und kostengünstigere Methode benötigen, um die Datenkapazität für Ihre MemoryDB-Cluster zu skalieren, ohne die Verfügbarkeit Ihrer Anwendungen zu beeinträchtigen. Daten-Tiering eignet sich ideal für Workloads, die regelmäßig auf bis zu 20 % ihrer Daten zugreifen, und für Anwendungen, die zusätzliche Latenzzeiten tolerieren, wenn ein Element mit geringerer Häufigkeit zum ersten Mal benötigt wird. Durch die Verwendung von Daten-Tiering mit R6gd-Knoten, die über eine fast 5-mal höhere Gesamtkapazität (Arbeitsspeicher und SSD) verfügen, können Sie bei maximaler Auslastung im Vergleich zu R6g-Knoten (nur Arbeitsspeicher) über 60 % der Speicherkosten einsparen. Geht man von 500-Byte-String-Werten aus, kann man typischerweise mit einer zusätzlichen Latenz von durchschnittlich 450 µs für Lese-Anfragen an auf SSD gespeicherte Daten im Vergleich zu Lese-Anfragen an Daten im Speicher rechnen.

Beim Daten-Tiering wird SSD-Speicher in Clusterknoten verwendet, wenn die verfügbare Speicherkapazität erschöpft ist. Wenn Clusterknoten mit SSD-Speicher verwendet werden, wird das Daten-Tiering automatisch aktiviert, und MemoryDB verwaltet die Datenplatzierung und verschiebt Elemente mithilfe einer LRU-Richtlinie (Least Recently Used) transparent zwischen Speicher und Festplatte. Wenn der Arbeitsspeicher vollständig verbraucht ist, erkennt MemoryDB automatisch, welche Elemente zuletzt verwendet wurden, und verschiebt deren Werte auf die Festplatte, um die Kosten zu optimieren. Wenn eine Anwendung ein Objekt von der Festplatte abrufen muss, verschiebt MemoryDB seinen Wert transparent in den Arbeitsspeicher, bevor die Anforderung verarbeitet wird, mit minimalen Auswirkungen auf die Leistung.

Erstellen Sie zunächst einen neuen MemoryDB-Cluster mithilfe speicheroptimierter Instances mit ARM-basierten AWS-Graviton2-Prozessoren und NVMe-SSDs (R6gd). Anschließend können Sie Daten aus einem vorhandenen Cluster migrieren, indem Sie einen Snapshot importieren.

R6gD-Nodes mit Daten-Tiering basieren auf der verbrauchten Instance-Stunde. Sie zahlen auch für Daten, die mit R6gd geschrieben werden, ähnlich wie bei anderen MemoryDB-Knotentypen. Weitere Informationen finden Sie auf der Seite mit den Preisen für MemoryDB.

Erstellen Sie zunächst einen neuen MemoryDB-Cluster mithilfe speicheroptimierter Instances mit ARM-basierten AWS-Graviton2-Prozessoren und NVMe-SSDs (R6gd). Anschließend können Sie Daten aus einem vorhandenen Cluster migrieren, indem Sie einen Snapshot importieren.

Reservierte MemoryDB-Knoten bieten Größenflexibilität innerhalb einer Knotenfamilie und einer AWS-Region. Das bedeutet, dass der herabgesetzte Preis für reservierte Knoten automatisch auf die Nutzung aller Größen in derselben Knotenfamilie angewendet wird. Wenn Sie beispielsweise einen reservierten Knoten r6g.xlarge erwerben und auf einen größeren Knoten r6g.2xlarge skalieren müssen, wird der vergünstigte Preis für Ihren reservierten Knoten automatisch auf die 50-prozentige Nutzung des Knotens r6g.2xlarge in derselben AWS-Region angewendet. Die Größenflexibilität reduziert den Zeitaufwand für die Verwaltung Ihrer reservierten Knoten. Dadurch, dass Sie nicht mehr an eine bestimmte Datenbankknotengröße gebunden sind, können Sie Ihren Rabatt optimal nutzen, selbst wenn sich Ihre Kapazitätsanforderungen ändern.

Die Preise für reservierte MemoryDB-Nodes basieren auf dem Knotentyp, der Laufzeit (ein oder drei Jahre), der Zahlungsoption (keine Vorauszahlung, teilweise Vorauszahlung, komplette Vorauszahlung) und der AWS-Region. Bitte beachten Sie, dass die Preise für reservierte Knoten nicht die Kosten für geschriebene Daten oder Snapshot-Speicher abdecken. Weitere Informationen finden Sie auf der Seite mit den Preisen für MemoryDB.

MemoryDB bietet reservierte Knoten für die speicheroptimierten R6g-, R7g- und R6gD-Knoten (mit Daten-Tiering).

Vektorsuche für MemoryDB unterstützt das Speichern von Millionen von Vektoren mit einstelligen Millisekunden-Anfragen und Antwortzeiten bei Aktualisierungen und erreicht gleichzeitig einen Abruf von über 99 %. Die Vektorsuche für MemoryDB kann Vektoren speichern, die Sie mit Services wie Amazon Bedrock und Amazon SageMaker generieren.

Sie sollten Vektorsuche für MemoryDB verwenden, wenn Sie Hochgeschwindigkeitsanwendungen für künstliche Intelligenz und Machine Learning (KI/ML) mithilfe der MemoryDB-API erstellen. Vektorsuche für MemoryDB eignet sich gut für Anwendungsfälle, bei denen Spitzenleistung das wichtigste Auswahlkriterium ist. Seit dem 26. Juni 2024 bietet MemoryDB die schnellste Vektorsuchleistung bei den höchsten Rückrufquoten unter den populären Vektordatenbanken in AWS. Sie können Vektorsuche für MemoryDB verwenden, um ML- und generative-KI-Anwendungsfälle wie Retrieval Augmented Generation (RAG), Anomalie- (Betrugs-)Erkennung, Echtzeit-Empfehlungsmaschinen und Dokumentabruf zu unterstützen.

Wenn eine KI/ML-gestützte Anwendung auf Geschwindigkeit konfiguriert wird, kann dies zu einer schlechteren Qualität der Antworten führen, gemessen anhand der Rückrufraten. Vektorsuche für MemoryDB bietet den höchsten Durchsatz mit einstelligen Millisekunden-Abfrage- und Aktualisierungsantwortzeiten, ohne Kompromisse beim Abrufen einzugehen, indem die Vektoren im Speicher gespeichert werden.

Mit Vektorsuche können Sie Vektoreinbettungen in MemoryDB zusammen mit Ihren Daten speichern, indizieren, abrufen und durchsuchen. Zunächst generieren Sie Vektoreinbettungen direkt über Einbettungsmodelle wie die Amazon Titan Embeddings oder über verwaltete Services wie Amazon Bedrock. Anschließend laden Sie die Einbettungen in MemoryDB, nachdem Sie Ihren Vektorindex mithilfe der MemoryDB-Datenebenen-APIs initialisiert haben. MemoryDB speichert Vektoreinbettungen als JSON- oder Hash-Datentypen. 

Beim Laden erstellt MemoryDB den Index mit Ihren Vektoreinbettungen. Wenn Sie neue Daten laden, vorhandene aktualisieren oder löschen, streamt MemoryDB Aktualisierungen des Vektorindex innerhalb einstelliger Millisekunden. MemoryDB unterstützt effiziente Suchanfragen, Vorfilterung und mehrere Entfernungsmetriken (Kosinus, Punktprodukt und Euklidisch). Weitere Informationen zur Verwendung von Vektorsuche für MemoryDB finden Sie in der Dokumentation.

Für die Verwendung von Vektorsuche für MemoryDB fallen keine zusätzlichen Kosten an. Besuchen Sie die Seite Preise für MemoryDB, um mehr zu erfahren.