Wie schlägt sich Rockset im Vergleich zu Elasticsearch in sekundären DynamoDB-Indizes?

Viele Entwicklungsteams nutzen DynamoDB, um ereignisgesteuerte Architekturen und benutzerfreundliche, leistungsstarke Anwendungen im großen Maßstab zu erstellen. Als operative Datenbank ist DynamoDB für Echtzeittransaktionen optimiert, selbst wenn es an mehreren geografischen Standorten eingesetzt wird. Für Such- und Analysezugriffsmuster bietet es jedoch keine starke Leistung.

Suche und Analyse auf DynamoDB

Während NoSQL-Datenbanken wie DynamoDB im Allgemeinen über hervorragende Skalierungseigenschaften verfügen, unterstützen sie nur eine begrenzte Anzahl von Operationen, die sich auf die Online-Transaktionsverarbeitung konzentrieren. Dies erschwert das Suchen, Filtern, Aggregieren und Zusammenführen von Daten, ohne sich stark auf effiziente Indizierungsstrategien zu stützen.

DynamoDB speichert Daten im Hintergrund, indem es sie auf eine große Anzahl von Knoten partitioniert, basierend auf einem benutzerdefinierten Partitionsschlüsselfeld, das in jedem Element vorhanden ist. Dieser benutzerdefinierte Partitionsschlüssel kann optional mit einem Sortierschlüssel kombiniert werden, um einen Primärschlüssel darzustellen. Der Primärschlüssel fungiert als Index, wodurch Abfragevorgänge kostengünstig sind. Ein Abfragevorgang kann Gleichheitsvergleiche (=) am Partitionsschlüssel und Vergleichsvorgänge (>, <, =, BETWEEN) am Sortierschlüssel durchführen, sofern angegeben.

Für die Durchführung analytischer Abfragen, die nicht im obigen Schema abgedeckt sind, ist ein Scanvorgang erforderlich, der normalerweise durch paralleles Scannen der gesamten DynamoDB-Tabelle ausgeführt wird. Diese Scans können hinsichtlich des Lesedurchsatzes langsam und teuer sein, da sie ein vollständiges Lesen der gesamten Tabelle erfordern. Scans werden außerdem tendenziell langsamer, wenn die Tabellengröße zunimmt, da mehr Daten gescannt werden müssen, um Ergebnisse zu erzielen. Wenn wir analytische Abfragen unterstützen möchten, ohne auf untragbare Scankosten zu stoßen, können wir sekundäre Indizes nutzen, die wir als Nächstes besprechen werden.

Indizierung in DynamoDB

In DynamoDB werden Sekundärindizes häufig verwendet, um die Anwendungsleistung durch Indizierung häufig abgefragter Felder zu verbessern. Abfragevorgänge für Sekundärindizes können auch verwendet werden, um bestimmte Funktionen durch analytische Abfragen mit klar definierten Anforderungen zu unterstützen.

Sekundärindizes bestehen aus der Erstellung von Partitionsschlüsseln und optionalen Sortierschlüsseln für die Felder, die wir abfragen möchten. Es gibt zwei Arten von Sekundärindizes:

• Lokale sekundäre Indizes (LSIs): LSIs erweitern die Hash- und Bereichsschlüsselattribute für eine einzelne Partition.

• Globale sekundäre Indizes (GSIs): GSIs sind Indizes, die auf eine ganze Tabelle statt auf eine einzelne Partition angewendet werden.

  
  

Wie Nike jedoch herausfand , kann die übermäßige Verwendung von GSIs in DynamoDB kostspielig sein. Analysen in DynamoDB können, sofern sie nicht nur für sehr einfache Punktsuchen oder kleine Bereichsscans verwendet werden, zu einer übermäßigen Verwendung sekundärer Indizes und hohen Kosten führen.

Die Kosten für bereitgestellte Kapazität bei der Verwendung von Indizes können sich schnell summieren, da alle Aktualisierungen der Basistabelle auch in den entsprechenden GSIs vorgenommen werden müssen. Tatsächlich empfiehlt AWS, dass die bereitgestellte Schreibkapazität für einen globalen sekundären Index gleich oder größer als die Schreibkapazität der Basistabelle sein sollte, um eine Drosselung der Schreibvorgänge in der Basistabelle und eine Beeinträchtigung der Anwendung zu vermeiden. Die Kosten für bereitgestellte Schreibkapazität steigen linear mit der Anzahl der konfigurierten GSIs, sodass die Verwendung vieler GSIs zur Unterstützung vieler Zugriffsmuster unerschwinglich wird.

DynamoDB ist außerdem nicht dafür geeignet, Daten in verschachtelten Strukturen, einschließlich Arrays und Objekten, zu indizieren. Vor der Indizierung der Daten müssen Benutzer die Daten denormalisieren und die verschachtelten Objekte und Arrays abflachen. Dies könnte die Anzahl der Schreibvorgänge und die damit verbundenen Kosten erheblich erhöhen.

Eine ausführlichere Untersuchung der Verwendung sekundärer DynamoDB-Indizes für Analysen finden Sie in unserem Blog „Sekundäre Indizes für Analysen auf DynamoDB“ .

Unter dem Strich lässt sich sagen, dass Sie bei analytischen Anwendungsfällen erhebliche Leistungs- und Kostenvorteile erzielen können, indem Sie die DynamoDB-Tabelle mit einem anderen Tool oder Dienst synchronisieren, der als externer Sekundärindex für die effiziente Ausführung komplexer Analysen fungiert.

DynamoDB + Elasticsearch

Ein Ansatz zum Erstellen eines sekundären Indexes für unsere Daten ist die Verwendung von DynamoDB mit Elasticsearch. Cloudbasiertes Elasticsearch, wie Elastic Cloud oder Amazon OpenSearch Service, kann zum Bereitstellen und Konfigurieren von Knoten entsprechend der Größe der Indizes, der Replikation und anderer Anforderungen verwendet werden. Ein verwalteter Cluster erfordert einige Vorgänge zum Aktualisieren, Sichern und Aufrechterhalten der Leistung, jedoch weniger, als wenn Sie ihn vollständig selbst auf EC2-Instanzen ausführen.

Da der Ansatz mit dem Logstash-Plugin für Amazon DynamoDB nicht unterstützt wird und ziemlich schwierig einzurichten ist, können wir stattdessen Schreibvorgänge von DynamoDB in Elasticsearch streamen, indem wir DynamoDB Streams und eine AWS Lambda-Funktion verwenden. Für diesen Ansatz müssen wir zwei separate Schritte ausführen:

• Wir erstellen zunächst eine Lambda-Funktion, die im DynamoDB-Stream aufgerufen wird, um jedes Update, sobald es in DynamoDB auftritt, in Elasticsearch zu veröffentlichen.
• Anschließend erstellen wir eine Lambda-Funktion (oder eine EC2-Instanz, die ein Skript ausführt, wenn dies länger dauert als das Timeout der Lambda-Ausführung), um den gesamten vorhandenen Inhalt von DynamoDB in Elasticsearch zu veröffentlichen.

Wir müssen diese beiden Lambda-Funktionen mit den richtigen Berechtigungen schreiben und verdrahten, um sicherzustellen, dass wir keine Schreibvorgänge in unseren Tabellen verpassen. Wenn sie zusammen mit der erforderlichen Überwachung eingerichtet sind, können wir Dokumente in Elasticsearch von DynamoDB empfangen und Elasticsearch verwenden, um analytische Abfragen für die Daten auszuführen.

Der Vorteil dieses Ansatzes besteht darin, dass Elasticsearch Volltextindizierung und mehrere Arten analytischer Abfragen unterstützt. Elasticsearch unterstützt Clients in verschiedenen Sprachen und Tools wie Kibana zur Visualisierung, mit denen sich Dashboards schnell erstellen lassen. Wenn ein Cluster richtig konfiguriert ist, können Abfragelatenzen für schnelle analytische Abfragen der in Elasticsearch fließenden Daten optimiert werden.

Zu den Nachteilen gehören die hohen Einrichtungs- und Wartungskosten der Lösung. Selbst verwaltetes Elasticsearch erfordert Replikation, Resharding, Indexwachstum und Leistungsoptimierung der zugrunde liegenden Instanzen.

Elasticsearch verfügt über eine eng gekoppelte Architektur, die Rechenleistung und Speicher nicht trennt. Dies bedeutet, dass Ressourcen häufig überdimensioniert werden, da sie nicht unabhängig voneinander skaliert werden können. Darüber hinaus konkurrieren mehrere Workloads, wie z. B. Lese- und Schreibvorgänge, um dieselben Rechenressourcen.

Elasticsearch kann Updates auch nicht effizient verarbeiten. Das Aktualisieren eines beliebigen Felds löst eine Neuindizierung des gesamten Dokuments aus. Elasticsearch-Dokumente sind unveränderlich, sodass für jedes Update ein neues Dokument indexiert und die alte Version als gelöscht markiert werden muss. Dies führt zu zusätzlichem Rechen- und I/O-Aufwand, um auch die unveränderten Felder neu zu indexieren und beim Update ganze Dokumente zu schreiben.

Da Lambdas ausgelöst werden, wenn sie ein Update im DynamoDB-Stream sehen, können sie aufgrund von Kaltstarts Latenzspitzen aufweisen. Das Setup erfordert Metriken und Überwachung, um sicherzustellen, dass es Ereignisse aus dem DynamoDB-Stream korrekt verarbeitet und in Elasticsearch schreiben kann.

Funktional gesehen fehlt Elasticsearch in Bezug auf analytische Abfragen die Unterstützung für Joins , die für komplexe analytische Abfragen mit mehr als einem Index nützlich sind. Elasticsearch-Benutzer müssen häufig Daten denormalisieren, anwendungsseitige Joins durchführen oder verschachtelte Objekte oder Eltern-Kind-Beziehungen verwenden, um diese Einschränkung zu umgehen.

Vorteile

• Unterstützung der Volltextsuche
• Unterstützung für verschiedene Arten analytischer Abfragen
• Kann mit den neuesten Daten in DynamoDB arbeiten

Nachteile

• Erfordert Verwaltung und Überwachung der Infrastruktur für Aufnahme, Indizierung, Replikation und Sharding
• Eine eng gekoppelte Architektur führt zu einer Überbereitstellung von Ressourcen und zu Konflikten bei der Datenverarbeitung
• Ineffiziente Updates
• Erfordert ein separates System, um die Datenintegrität und -konsistenz zwischen DynamoDB und Elasticsearch sicherzustellen
• Keine Unterstützung für Verknüpfungen zwischen verschiedenen Indizes

Dieser Ansatz kann gut funktionieren, wenn die Volltextsuche in den Daten in DynamoDB und Dashboards mit Kibana implementiert wird. Die zum Optimieren und Warten eines Elasticsearch-Clusters in der Produktion erforderlichen Vorgänge, die ineffiziente Nutzung von Ressourcen und das Fehlen von Join-Funktionen können jedoch eine Herausforderung darstellen.

DynamoDB + Rockset

Rockset ist eine vollständig verwaltete Such- und Analysedatenbank, die in erster Linie zur Unterstützung von Echtzeitanwendungen mit hohen QPS-Anforderungen entwickelt wurde. Sie wird häufig als externer Sekundärindex für Daten aus OLTP-Datenbanken verwendet.

Rockset verfügt über einen integrierten Connector mit DynamoDB, mit dem Daten zwischen DynamoDB und Rockset synchron gehalten werden können. Wir können die DynamoDB-Tabelle angeben, deren Inhalte wir synchronisieren möchten, und eine Rockset-Sammlung, die die Tabelle indiziert. Rockset indiziert den Inhalt der DynamoDB-Tabelle in einem vollständigen Snapshot und synchronisiert dann neue Änderungen, sobald sie auftreten. Der Inhalt der Rockset-Sammlung ist immer mit der DynamoDB-Quelle synchronisiert; im stationären Zustand liegt die Abweichung höchstens ein paar Sekunden.

Rockset verwaltet die Datenintegrität und -konsistenz zwischen der DynamoDB-Tabelle und der Rockset-Sammlung automatisch, indem es den Status des Streams überwacht und Einblick in die Streaming-Änderungen von DynamoDB bietet.

Ohne Schemadefinition kann sich eine Rockset-Sammlung automatisch anpassen, wenn Felder hinzugefügt/entfernt werden oder wenn sich die Struktur/der Typ der Daten selbst in DynamoDB ändert. Dies wird durch starke dynamische Typisierung undintelligente Schemata ermöglicht, die zusätzliches ETL überflüssig machen.

Die Rockset-Sammlung, die wir von DynamoDB bezogen haben, unterstützt SQL für Abfragen und kann von Entwicklern problemlos verwendet werden, ohne dass sie eine domänenspezifische Sprache erlernen müssen. Sie kann auch verwendet werden, um Abfragen an Anwendungen über eine REST-API oder mithilfe von Client-Bibliotheken in mehreren Programmiersprachen zu stellen. Die Obermenge von ANSI SQL, die Rockset unterstützt, kann nativ mit tief verschachtelten JSON-Arrays und -Objekten arbeiten und Indizes nutzen, die automatisch über alle Felder hinweg erstellt werden, um selbst bei komplexen analytischen Abfragen Latenzen im Millisekundenbereich zu erreichen.

Rockset ist ein Pionier der Compute-Compute-Trennung , die die Isolierung von Workloads in separaten Recheneinheiten ermöglicht, während dieselben zugrunde liegenden Echtzeitdaten gemeinsam genutzt werden. Dies bietet Benutzern eine höhere Ressourceneffizienz bei der Unterstützung gleichzeitiger Aufnahme und Abfragen oder mehrerer Anwendungen auf demselben Datensatz.

Darüber hinaus kümmert sich Rockset um Sicherheit, Verschlüsselung der Daten und rollenbasierte Zugriffskontrolle zur Verwaltung des Zugriffs darauf. Rockset-Benutzer können die Notwendigkeit von ETL vermeiden, indem sie Ingest-Transformationen nutzen, die wir in Rockset einrichten können, um die Daten zu ändern, wenn sie in einer Sammlung ankommen. Benutzer können optional auch den Lebenszyklus der Daten verwalten, indem sie Aufbewahrungsrichtlinien einrichten, um ältere Daten automatisch zu löschen. Sowohl die Datenaufnahme als auch die Abfragebereitstellung werden automatisch verwaltet, sodass wir uns auf das Erstellen und Bereitstellen von Live-Dashboards und -Anwendungen konzentrieren können und die Notwendigkeit der Infrastrukturverwaltung und des Betriebs entfällt.

Besonders relevant im Zusammenhang mit der Synchronisierung mit DynamoDB ist, dass Rockset direkte Aktualisierungen auf Feldebene unterstützt, um eine kostspielige Neuindizierung zu vermeiden. Vergleichen Sie Rockset und Elasticsearch hinsichtlich Aufnahme, Abfrage und Effizienz, um das richtige Tool für die jeweilige Aufgabe auszuwählen.

Zusammenfassung

• Entwickelt, um hohe QPS zu liefern und Echtzeitanwendungen zu unterstützen
• Komplett serverlos. Kein Betrieb oder Bereitstellung von Infrastruktur oder Datenbank erforderlich
• Trennung von Rechenleistung und Rechenleistung für vorhersehbare Leistung und effiziente Ressourcennutzung
• Live-Synchronisierung zwischen DynamoDB und der Rockset-Sammlung, sodass die Daten nie mehr als ein paar Sekunden auseinander liegen
• Überwachung zur Gewährleistung der Konsistenz zwischen DynamoDB und Rockset
• Automatische Indizes, die über die Daten erstellt werden und Abfragen mit geringer Latenz ermöglichen
• Direkte Updates vermeiden eine aufwändige Neuindizierung und verringern die Datenlatenz
• Verbindet Daten mit anderen Quellen wie Amazon Kinesis, Apache Kafka, Amazon S3 usw.

Wir können Rockset verwenden, um Echtzeitanalysen der Daten in DynamoDB zu implementieren, ohne dass wir uns um Betrieb, Skalierung oder Wartung kümmern müssen. Dies kann die Entwicklung von Echtzeitanwendungen erheblich beschleunigen. Wenn Sie Ihre Anwendung mit Rockset auf DynamoDB-Daten erstellen möchten, können Sie hier kostenlos loslegen.