Wann werden sekundäre DynamoDB-Indizes verwendet?

Indizes sind ein entscheidender Teil der richtigen Datenmodellierung für alle Datenbanken, und DynamoDB bildet hier keine Ausnahme. Die sekundären Indizes von DynamoDB sind ein leistungsstarkes Tool, um neue Zugriffsmuster für Ihre Daten zu ermöglichen.

In diesem Beitrag werden wir uns die sekundären Indizes von DynamoDB ansehen. Zunächst beginnen wir mit einigen konzeptionellen Punkten zu DynamoDB und den Problemen, die sekundäre Indizes lösen. Anschließend sehen wir uns einige praktische Tipps für die effektive Verwendung sekundärer Indizes an. Abschließend geben wir einige Überlegungen dazu, wann Sie sekundäre Indizes verwenden sollten und wann Sie nach anderen Lösungen suchen sollten.

Lass uns anfangen.

Was ist DynamoDB und was sind sekundäre DynamoDB-Indizes?

Bevor wir uns mit Anwendungsfällen und Best Practices für Sekundärindizes befassen, sollten wir zunächst verstehen, was Sekundärindizes von DynamoDB sind. Und dazu sollten wir ein wenig darüber verstehen, wie DynamoDB funktioniert.

Dies setzt ein gewisses Grundverständnis von DynamoDB voraus. Wir behandeln die grundlegenden Punkte, die Sie zum Verständnis sekundärer Indizes wissen müssen. Wenn Sie jedoch neu bei DynamoDB sind, möchten Sie vielleicht mit einer grundlegenderen Einführung beginnen.

Das absolute Minimum, das Sie über DynamoDB wissen müssen

DynamoDB ist eine einzigartige Datenbank. Sie ist für OLTP-Workloads konzipiert, was bedeutet, dass sie sich hervorragend für die Verarbeitung einer großen Anzahl kleiner Vorgänge eignet – denken Sie beispielsweise an Dinge wie das Hinzufügen eines Artikels zu einem Einkaufswagen, das Liken eines Videos oder das Hinzufügen eines Kommentars auf Reddit. Auf diese Weise kann sie ähnliche Anwendungen verarbeiten wie andere Datenbanken, die Sie möglicherweise verwendet haben, z. B. MySQL, PostgreSQL, MongoDB oder Cassandra.

Das wichtigste Versprechen von DynamoDB ist die Garantie einer gleichbleibenden Leistung in jedem Maßstab . Unabhängig davon, ob Ihre Tabelle 1 Megabyte oder 1 Petabyte Daten enthält, möchte DynamoDB für Ihre OLTP-ähnlichen Anfragen die gleiche Latenz haben. Das ist ein großes Problem – bei vielen Datenbanken verringert sich die Leistung, wenn Sie die Datenmenge oder die Anzahl gleichzeitiger Anfragen erhöhen. Um diese Garantien zu bieten, sind jedoch einige Kompromisse erforderlich, und DynamoDB weist einige einzigartige Merkmale auf, die Sie verstehen müssen, um es effektiv nutzen zu können.

Erstens skaliert DynamoDB Ihre Datenbanken horizontal, indem es Ihre Daten im Hintergrund auf mehrere Partitionen verteilt. Diese Partitionen sind für Sie als Benutzer nicht sichtbar, bilden jedoch den Kern der Funktionsweise von DynamoDB. Sie geben einen Primärschlüssel für Ihre Tabelle an (entweder ein einzelnes Element, das als „Partitionsschlüssel“ bezeichnet wird, oder eine Kombination aus einem Partitionsschlüssel und einem Sortierschlüssel), und DynamoDB verwendet diesen Primärschlüssel, um zu bestimmen, auf welcher Partition Ihre Daten gespeichert sind. Jede Anfrage, die Sie stellen, wird über einen Anfragerouter geleitet, der bestimmt, welche Partition die Anfrage verarbeiten soll. Diese Partitionen sind klein – im Allgemeinen 10 GB oder weniger –, sodass sie unabhängig voneinander verschoben, aufgeteilt, repliziert und anderweitig verwaltet werden können.

Horizontale Skalierbarkeit über Sharding ist interessant, aber keineswegs nur DynamoDB vorbehalten. Viele andere Datenbanken – sowohl relationale als auch nicht-relationale – verwenden Sharding zur horizontalen Skalierung. Was DynamoDB jedoch einzigartig macht , ist die Tatsache, dass Sie gezwungen werden, Ihren Primärschlüssel zu verwenden, um auf Ihre Daten zuzugreifen. Anstatt einen Abfrageplaner zu verwenden, der Ihre Anfragen in eine Reihe von Abfragen übersetzt, zwingt DynamoDB Sie, Ihren Primärschlüssel zu verwenden, um auf Ihre Daten zuzugreifen. Sie erhalten im Wesentlichen einen direkt adressierbaren Index für Ihre Daten.

Die API für DynamoDB spiegelt dies wider. Es gibt eine Reihe von Operationen für einzelne Elemente ( GetItem , PutItem , UpdateItem , DeleteItem ), mit denen Sie einzelne Elemente lesen, schreiben und löschen können. Darüber hinaus gibt es eine Query , mit der Sie mehrere Elemente mit demselben Partitionsschlüssel abrufen können. Wenn Sie eine Tabelle mit einem zusammengesetzten Primärschlüssel haben, werden Elemente mit demselben Partitionsschlüssel in derselben Partition zusammengefasst. Sie werden nach dem Sortierschlüssel sortiert, sodass Sie Muster wie „Die neuesten Bestellungen für einen Benutzer abrufen“ oder „Die letzten 10 Sensorwerte für ein IoT-Gerät abrufen“ verarbeiten können.

Stellen wir uns beispielsweise eine SaaS-Anwendung vor, die eine Tabelle mit Benutzern enthält. Alle Benutzer gehören zu einer einzigen Organisation. Unsere Tabelle könnte wie folgt aussehen:

Wir verwenden einen zusammengesetzten Primärschlüssel mit dem Partitionsschlüssel „Organisation“ und dem Sortierschlüssel „Benutzername“. Dadurch können wir Vorgänge ausführen, um einen einzelnen Benutzer abzurufen oder zu aktualisieren, indem wir dessen Organisation und Benutzernamen angeben. Wir können auch alle Benutzer für eine einzelne Organisation abrufen, indem wir nur die Organisation für einen Query angeben.

Was sind Sekundärindizes und wie funktionieren sie?

Nach diesen Grundlagen wollen wir uns nun Sekundärindizes ansehen. Die beste Möglichkeit, die Notwendigkeit von Sekundärindizes zu verstehen, besteht darin, das Problem zu verstehen, das sie lösen. Wir haben gesehen, wie DynamoDB Ihre Daten entsprechend Ihrem Primärschlüssel partitioniert und wie es Sie dazu zwingt, den Primärschlüssel für den Zugriff auf Ihre Daten zu verwenden. Für einige Zugriffsmuster ist das alles schön und gut, aber was ist, wenn Sie auf eine andere Weise auf Ihre Daten zugreifen müssen?

In unserem obigen Beispiel hatten wir eine Tabelle mit Benutzern, auf die wir über ihre Organisation und ihren Benutzernamen zugegriffen haben. Möglicherweise müssen wir jedoch auch einen einzelnen Benutzer über seine E-Mail-Adresse abrufen. Dieses Muster passt nicht zum Primärschlüssel-Zugriffsmuster, das DynamoDB uns vorgibt. Da unsere Tabelle nach verschiedenen Attributen partitioniert ist, gibt es keine klare Möglichkeit, auf die gewünschte Weise auf unsere Daten zuzugreifen. Wir könnten einen vollständigen Tabellenscan durchführen, aber das ist langsam und ineffizient. Wir könnten unsere Daten in eine separate Tabelle mit einem anderen Primärschlüssel duplizieren, aber das erhöht die Komplexität.

Hier kommen sekundäre Indizes ins Spiel. Ein sekundärer Index ist im Grunde eine vollständig verwaltete Kopie Ihrer Daten mit einem anderen Primärschlüssel. Sie geben einen sekundären Index für Ihre Tabelle an, indem Sie den Primärschlüssel für den Index deklarieren. Wenn Schreibvorgänge in Ihre Tabelle eingehen, repliziert DynamoDB die Daten automatisch in Ihren sekundären Index.

Hinweis *: Alles in diesem Abschnitt gilt für globale sekundäre Indizes. DynamoDB bietet auch lokale sekundäre Indizes, die etwas anders sind. In fast allen Fällen werden Sie einen globalen sekundären Index benötigen. Weitere Einzelheiten zu den Unterschieden finden Sie in diesem Artikel zur Auswahl eines globalen oder lokalen sekundären Indexes .*

In diesem Fall fügen wir unserer Tabelle einen sekundären Index mit dem Partitionsschlüssel „Email“ hinzu. Der sekundäre Index sieht wie folgt aus:

Beachten Sie, dass es sich um dieselben Daten handelt, sie wurden lediglich mit einem anderen Primärschlüssel neu organisiert. Jetzt können wir einen Benutzer effizient anhand seiner E-Mail-Adresse suchen.

In mancher Hinsicht ist dies einem Index in anderen Datenbanken sehr ähnlich. Beide bieten eine Datenstruktur, die für die Suche nach einem bestimmten Attribut optimiert ist. Die sekundären Indizes von DynamoDB unterscheiden sich jedoch in einigen wesentlichen Punkten.

Erstens und am wichtigsten: Die Indizes von DynamoDB befinden sich auf ganz anderen Partitionen als Ihre Haupttabelle. DynamoDB möchte, dass jede Suche effizient und vorhersehbar ist, und es möchte eine lineare horizontale Skalierung ermöglichen. Dazu muss es Ihre Daten nach den Attributen neu partitionieren, die Sie zur Abfrage verwenden.

In anderen verteilten Datenbanken werden Ihre Daten für den sekundären Index im Allgemeinen nicht neu aufgeteilt. Normalerweise wird nur der sekundäre Index für alle Daten auf dem Shard verwaltet. Wenn Ihre Indizes jedoch den Shard-Schlüssel nicht verwenden, verlieren Sie einige der Vorteile der horizontalen Skalierung Ihrer Daten, da eine Abfrage ohne den Shard-Schlüssel einen Scatter-Gather-Vorgang über alle Shards hinweg ausführen muss, um die gesuchten Daten zu finden.

Ein zweiter Unterschied der sekundären Indizes von DynamoDB besteht darin, dass sie (häufig) das gesamte Element in den sekundären Index kopieren. Bei Indizes in einer relationalen Datenbank enthält der Index häufig einen Zeiger auf den Primärschlüssel des indizierten Elements. Nachdem ein relevanter Datensatz im Index gefunden wurde, muss die Datenbank das vollständige Element abrufen. Da sich die sekundären Indizes von DynamoDB auf anderen Knoten als die Haupttabelle befinden, soll ein Netzwerksprung zurück zum ursprünglichen Element vermieden werden. Stattdessen kopieren Sie so viele Daten wie Sie zum Lesen benötigen in den sekundären Index.

Sekundärindizes in DynamoDB sind leistungsstark, haben aber einige Einschränkungen. Erstens sind sie schreibgeschützt – Sie können nicht direkt in einen Sekundärindex schreiben. Stattdessen schreiben Sie in Ihre Haupttabelle und DynamoDB übernimmt die Replikation in Ihren Sekundärindex. Zweitens werden Ihnen die Schreibvorgänge in Ihren Sekundärindizes in Rechnung gestellt. Wenn Sie Ihrer Tabelle also einen Sekundärindex hinzufügen, verdoppeln sich häufig die Gesamtschreibkosten für Ihre Tabelle.

Tipps zur Verwendung von Sekundärindizes

Nachdem wir nun wissen, was Sekundärindizes sind und wie sie funktionieren, wollen wir darüber sprechen, wie man sie effektiv einsetzt. Sekundärindizes sind ein mächtiges Werkzeug, aber sie können missbraucht werden. Hier sind einige Tipps für die effektive Verwendung von Sekundärindizes.

Versuchen Sie, schreibgeschützte Muster für sekundäre Indizes zu verwenden

Der erste Tipp scheint offensichtlich: Sekundärindizes können nur zum Lesen verwendet werden. Sie sollten also versuchen, schreibgeschützte Muster für Ihre Sekundärindizes zu verwenden! Und dennoch sehe ich diesen Fehler ständig. Entwickler lesen zuerst aus einem Sekundärindex und schreiben dann in die Haupttabelle. Dies führt zu zusätzlichen Kosten und zusätzlicher Latenz und lässt sich mit etwas Vorausplanung oft vermeiden.

Wenn Sie etwas über die Datenmodellierung in DynamoDB gelesen haben, wissen Sie wahrscheinlich, dass Sie zuerst über Ihre Zugriffsmuster nachdenken sollten. Es ist nicht wie bei einer relationalen Datenbank, bei der Sie zuerst normalisierte Tabellen entwerfen und dann Abfragen schreiben, um sie miteinander zu verknüpfen. In DynamoDB sollten Sie über die Aktionen nachdenken, die Ihre Anwendung ausführen wird, und dann Ihre Tabellen und Indizes so entwerfen, dass sie diese Aktionen unterstützen.

Beim Entwerfen meiner Tabelle beginne ich gerne zuerst mit den schreibbasierten Zugriffsmustern. Bei meinen Schreibvorgängen behalte ich häufig eine Art Einschränkung bei – die Eindeutigkeit eines Benutzernamens oder eine maximale Anzahl von Mitgliedern in einer Gruppe. Ich möchte meine Tabelle so entwerfen, dass dies unkompliziert ist, idealerweise ohne die Verwendung von DynamoDB-Transaktionen oder eines Lese-Änderungs-Schreib-Musters, das zu Race Conditions führen könnte.

Während Sie diese durcharbeiten, werden Sie im Allgemeinen feststellen, dass es eine „primäre“ Möglichkeit gibt, Ihren Artikel zu identifizieren, die mit Ihren Schreibmustern übereinstimmt. Dies wird letztendlich Ihr Primärschlüssel sein. Mit sekundären Indizes ist das Hinzufügen zusätzlicher, sekundärer Lesemuster dann ganz einfach.

In unserem vorherigen Benutzerbeispiel wird jede Benutzeranfrage wahrscheinlich die Organisation und den Benutzernamen enthalten. Dadurch kann ich den einzelnen Benutzerdatensatz nachschlagen und bestimmte Aktionen des Benutzers autorisieren. Die Suche nach E-Mail-Adressen kann für weniger auffällige Zugriffsmuster wie den Ablauf „Passwort vergessen“ oder „Benutzer suchen“ verwendet werden. Dies sind schreibgeschützte Muster, die gut zu einem sekundären Index passen.

Verwenden Sie sekundäre Indizes, wenn Ihre Schlüssel veränderbar sind

Ein zweiter Tipp zur Verwendung sekundärer Indizes besteht darin, sie für veränderliche Werte in Ihren Zugriffsmustern zu verwenden. Lassen Sie uns zunächst die Gründe dafür verstehen und dann Situationen betrachten, in denen dies zutrifft.

DynamoDB ermöglicht Ihnen, ein vorhandenes Element mit der UpdateItem Operation zu aktualisieren. Sie können den Primärschlüssel eines Elements jedoch nicht in einem Update ändern . Der Primärschlüssel ist die eindeutige Kennung für ein Element, und das Ändern des Primärschlüssels ist im Grunde das Erstellen eines neuen Elements. Wenn Sie den Primärschlüssel eines vorhandenen Elements ändern möchten, müssen Sie das alte Element löschen und ein neues erstellen. Dieser zweistufige Prozess ist langsamer und kostspieliger. Oft müssen Sie zuerst das Originalelement lesen und dann eine Transaktion verwenden, um das Originalelement zu löschen und in derselben Anfrage ein neues zu erstellen.

Wenn Sie andererseits diesen veränderbaren Wert im Primärschlüssel eines sekundären Indexes haben, übernimmt DynamoDB diesen Lösch- und Erstellungsprozess während der Replikation für Sie. Sie können eine einfache UpdateItem Anforderung senden, um den Wert zu ändern, und DynamoDB übernimmt den Rest.

Ich sehe dieses Muster in zwei Hauptsituationen. Die erste und häufigste ist, wenn Sie ein veränderliches Attribut haben, nach dem Sie sortieren möchten. Die kanonischen Beispiele hierfür sind eine Bestenliste für ein Spiel, bei dem die Leute ständig Punkte sammeln, oder eine ständig aktualisierte Liste von Elementen, bei der Sie die zuletzt aktualisierten Elemente zuerst anzeigen möchten. Denken Sie an etwas wie Google Drive, wo Sie Ihre Dateien nach „zuletzt geändert“ sortieren können.

Ein zweites Muster, bei dem dies auftritt, ist, wenn Sie ein veränderliches Attribut haben, nach dem Sie filtern möchten. Hier können Sie an einen E-Commerce-Shop mit einem Bestellverlauf für einen Benutzer denken. Sie möchten dem Benutzer möglicherweise erlauben, seine Bestellungen nach Status zu filtern – zeigen Sie mir alle meine Bestellungen, die „versendet“ oder „geliefert“ sind. Sie können dies in Ihren Partitionsschlüssel oder den Anfang Ihres Sortierschlüssels einbauen, um eine exakte Übereinstimmungsfilterung zu ermöglichen. Wenn der Artikel seinen Status ändert, können Sie das Statusattribut aktualisieren und sich auf DynamoDB verlassen, um die Artikel in Ihrem sekundären Index richtig zu gruppieren.

In beiden Fällen sparen Sie Zeit und Geld, wenn Sie dieses veränderbare Attribut in Ihren sekundären Index verschieben. Sie sparen Zeit, indem Sie das Muster Lesen-Ändern-Schreiben vermeiden, und Sie sparen Geld, indem Sie die zusätzlichen Schreibkosten der Transaktion vermeiden.

Beachten Sie außerdem, dass dieses Muster gut zum vorherigen Tipp passt. Es ist unwahrscheinlich, dass Sie ein Element zum Schreiben anhand des veränderlichen Attributs wie seiner vorherigen Punktzahl, seines vorherigen Status oder des letzten Aktualisierungszeitpunkts identifizieren. Stattdessen aktualisieren Sie anhand eines dauerhafteren Werts wie der Benutzer-ID, der Bestell-ID oder der Datei-ID. Anschließend verwenden Sie den sekundären Index zum Sortieren und Filtern basierend auf dem veränderlichen Attribut.

Vermeiden Sie die „fette“ Partition

Wir haben oben gesehen, dass DynamoDB Ihre Daten basierend auf dem Primärschlüssel in Partitionen aufteilt. DynamoDB versucht, diese Partitionen klein zu halten – 10 GB oder weniger – und Sie sollten versuchen, Anfragen auf Ihre Partitionen zu verteilen, um die Vorteile der Skalierbarkeit von DynamoDB zu nutzen.

Dies bedeutet im Allgemeinen, dass Sie in Ihrem Partitionsschlüssel einen Wert mit hoher Kardinalität verwenden sollten. Denken Sie beispielsweise an einen Benutzernamen, eine Bestell-ID oder eine Sensor-ID. Für diese Attribute gibt es eine große Anzahl von Werten, und DynamoDB kann den Datenverkehr auf Ihre Partitionen verteilen.

Ich erlebe oft, dass Leute dieses Prinzip in ihrer Haupttabelle verstehen, es dann aber in ihren sekundären Indizes völlig vergessen. Oft möchten sie eine Sortierung in der gesamten Tabelle für einen Artikeltyp. Wenn sie Benutzer alphabetisch abrufen möchten, verwenden sie einen sekundären Index, in dem alle Benutzer USERS als Partitionsschlüssel und den Benutzernamen als Sortierschlüssel haben. Oder wenn sie eine Sortierung der neuesten Bestellungen in einem E-Commerce-Shop wünschen, verwenden sie einen sekundären Index, in dem alle Bestellungen ORDERS als Partitionsschlüssel und den Zeitstempel als Sortierschlüssel haben.

Dieses Muster kann für Anwendungen mit geringem Datenverkehr funktionieren, bei denen Sie nicht an die Durchsatzgrenzen der DynamoDB-Partition herankommen, es ist jedoch ein gefährliches Muster für Anwendungen mit hohem Datenverkehr. Ihr gesamter Datenverkehr wird möglicherweise auf eine einzige physische Partition geleitet, und Sie können schnell die Schreibdurchsatzgrenzen für diese Partition erreichen.

Darüber hinaus und am gefährlichsten kann dies Probleme für Ihre Haupttabelle verursachen. Wenn Ihr sekundärer Index während der Replikation gedrosselt wird, wird die Replikationswarteschlange gesichert. Wenn diese Warteschlange zu stark gesichert wird, beginnt DynamoDB, Schreibvorgänge in Ihrer Haupttabelle abzulehnen.

Dies soll Ihnen helfen – DynamoDB möchte die Veralterung Ihres sekundären Indexes begrenzen und verhindert so, dass Ihr sekundärer Index eine große Verzögerung aufweist. Es kann jedoch eine überraschende Situation sein, die dann auftritt, wenn Sie am wenigsten damit rechnen.

Verwenden Sie spärliche Indizes als globalen Filter

Sekundärindizes werden oft als Möglichkeit betrachtet, alle Daten mit einem neuen Primärschlüssel zu replizieren. Allerdings müssen nicht alle Daten in einem Sekundärindex landen. Wenn Sie ein Element haben, das nicht dem Schlüsselschema des Index entspricht, wird es nicht in den Index repliziert.

Dies kann sehr nützlich sein, um einen globalen Filter für Ihre Daten bereitzustellen. Das kanonische Beispiel, das ich hierfür verwende, ist ein Nachrichten-Posteingang. In Ihrer Haupttabelle können Sie alle Nachrichten für einen bestimmten Benutzer speichern, sortiert nach dem Zeitpunkt ihrer Erstellung.

Aber wenn Sie so sind wie ich, haben Sie eine Menge Nachrichten in Ihrem Posteingang. Außerdem behandeln Sie ungelesene Nachrichten vielleicht wie eine „To-do“-Liste, wie kleine Erinnerungen, sich bei jemandem zu melden. Dementsprechend möchte ich normalerweise nur die ungelesenen Nachrichten in meinem Posteingang sehen.

Sie könnten Ihren sekundären Index verwenden, um diesen globalen Filter bereitzustellen, bei dem unread == true . Vielleicht ist Ihr sekundärer Indexpartitionsschlüssel so etwas wie ${userId}#UNREAD und der Sortierschlüssel ist der Zeitstempel der Nachricht. Wenn Sie die Nachricht anfänglich erstellen, enthält sie den Wert des sekundären Indexpartitionsschlüssels und wird somit in den sekundären Index für ungelesene Nachrichten repliziert. Später, wenn ein Benutzer die Nachricht liest, können Sie den status in READ ändern und den Wert des sekundären Indexpartitionsschlüssels löschen. DynamoDB entfernt ihn dann aus Ihrem sekundären Index.

Ich verwende diesen Trick ständig und er ist bemerkenswert effektiv. Außerdem spart Ihnen ein spärlicher Index Geld. Alle Aktualisierungen gelesener Nachrichten werden nicht auf den sekundären Index repliziert und Sie sparen Schreibkosten.

Schränken Sie Ihre sekundären Indexprojektionen ein, um die Indexgröße und/oder Schreibvorgänge zu reduzieren.

Für unseren letzten Tipp gehen wir etwas weiter als der vorherige Punkt. Wir haben gerade gesehen, dass DynamoDB ein Element nicht in Ihren sekundären Index aufnimmt, wenn das Element nicht die Primärschlüsselelemente für den Index hat. Dieser Trick kann nicht nur für Primärschlüsselelemente, sondern auch für Nicht-Schlüsselattribute in den Daten verwendet werden!

Wenn Sie einen sekundären Index erstellen, können Sie angeben, welche Attribute aus der Haupttabelle Sie in den sekundären Index aufnehmen möchten. Dies wird als Projektion des Indexes bezeichnet. Sie können wählen, ob Sie alle Attribute aus der Haupttabelle, nur die Primärschlüsselattribute oder eine Teilmenge der Attribute aufnehmen möchten.

Es ist zwar verlockend, alle Attribute in Ihren sekundären Index aufzunehmen, aber das kann ein kostspieliger Fehler sein. Denken Sie daran, dass jeder Schreibvorgang in Ihre Haupttabelle, der den Wert eines projizierten Attributs ändert, in Ihren sekundären Index repliziert wird. Ein einzelner sekundärer Index mit vollständiger Projektion verdoppelt effektiv die Schreibkosten für Ihre Tabelle. Jeder zusätzliche sekundäre Index erhöht Ihre Schreibkosten um 1/N + 1 , wobei N die Anzahl der sekundären Indizes vor dem neuen ist.

Darüber hinaus werden Ihre Schreibkosten basierend auf der Größe Ihres Artikels berechnet. Für jedes 1 KB an Daten, das in Ihre Tabelle geschrieben wird, wird eine WCU verwendet. Wenn Sie einen 4 KB großen Artikel in Ihren sekundären Index kopieren, zahlen Sie die vollen 4 WCUs sowohl für Ihre Haupttabelle als auch für Ihren sekundären Index.

Es gibt also zwei Möglichkeiten, wie Sie durch die Einschränkung Ihrer sekundären Indexprojektionen Geld sparen können. Erstens können Sie bestimmte Schreibvorgänge ganz vermeiden. Wenn Sie einen Aktualisierungsvorgang haben, der keine Attribute in Ihrer sekundären Indexprojektion berührt, überspringt DynamoDB den Schreibvorgang in Ihren sekundären Index. Zweitens können Sie bei Schreibvorgängen, die in Ihren sekundären Index repliziert werden, Geld sparen, indem Sie die Größe des replizierten Elements reduzieren.

Es kann schwierig sein, den richtigen Ausgleich zu finden. Sekundärindexprojektionen können nach der Indexerstellung nicht mehr geändert werden. Wenn Sie feststellen, dass Sie zusätzliche Attribute in Ihrem sekundären Index benötigen, müssen Sie einen neuen Index mit der neuen Projektion erstellen und dann den alten Index löschen.

Sollten Sie einen sekundären Index verwenden?

Nachdem wir nun einige praktische Ratschläge zu Sekundärindizes untersucht haben, gehen wir einen Schritt zurück und stellen eine grundlegendere Frage: Sollten Sie überhaupt einen Sekundärindex verwenden?

Wie wir gesehen haben, helfen Ihnen sekundäre Indizes, auf andere Weise auf Ihre Daten zuzugreifen. Dies geht jedoch auf Kosten der zusätzlichen Schreibvorgänge. Daher lautet meine Faustregel für sekundäre Indizes:

Verwenden Sie sekundäre Indizes, wenn die reduzierten Lesekosten die erhöhten Schreibkosten überwiegen.

Das klingt zwar offensichtlich, wenn man es sagt, aber beim Modellieren kann es kontraintuitiv sein. Es scheint so einfach zu sagen „Wirf es in einen sekundären Index“, ohne über andere Ansätze nachzudenken.

Um dies zu verdeutlichen, schauen wir uns zwei Situationen an, in denen sekundäre Indizes möglicherweise keinen Sinn ergeben.

Viele filterbare Attribute in kleinen Artikelsammlungen

Bei DynamoDB möchten Sie im Allgemeinen, dass Ihre Primärschlüssel die Filterung für Sie übernehmen. Es ärgert mich ein wenig, wenn ich eine Abfrage in DynamoDB verwende, dann aber meine eigene Filterung in meiner Anwendung durchführe – warum kann ich das nicht einfach in den Primärschlüssel einbauen?

Trotz meiner instinktiven Reaktion gibt es einige Situationen, in denen Sie Ihre Daten möglicherweise übermäßig lesen und dann in Ihrer Anwendung filtern möchten.

Am häufigsten kommt dies dann vor, wenn Sie Ihren Benutzern viele verschiedene Filter für Ihre Daten bereitstellen möchten, der relevante Datensatz jedoch begrenzt ist.

Denken Sie an einen Trainingstracker. Sie möchten Benutzern vielleicht das Filtern nach vielen Attributen ermöglichen, wie z. B. Trainingsart, Intensität, Dauer, Datum usw. Die Anzahl der Trainingseinheiten eines Benutzers ist jedoch überschaubar – selbst ein Poweruser wird eine Weile brauchen, um über 1000 Trainingseinheiten zu kommen. Anstatt alle diese Attribute indizieren zu müssen, können Sie einfach alle Trainingseinheiten des Benutzers abrufen und dann in Ihrer Anwendung filtern.

Hier empfehle ich , die Berechnung durchzuführen . Mit DynamoDB können Sie diese beiden Optionen ganz einfach berechnen und ein Gefühl dafür bekommen, welche für Ihre Anwendung besser geeignet ist.

Viele filterbare Attribute in großen Artikelsammlungen

Lassen Sie uns die Situation ein wenig ändern – was ist, wenn unsere Artikelsammlung groß ist? Was ist, wenn wir einen Trainingstracker für ein Fitnessstudio erstellen und dem Fitnessstudiobesitzer ermöglichen möchten, für alle Benutzer im Fitnessstudio nach allen oben genannten Attributen zu filtern?

Das ändert die Situation. Jetzt sprechen wir von Hunderten oder sogar Tausenden von Benutzern, jeder mit Hunderten oder Tausenden von Trainingseinheiten. Es ergibt keinen Sinn, die gesamte Artikelsammlung zu sehr zu lesen und die Ergebnisse nachträglich zu filtern.

Aber auch hier machen Sekundärindizes keinen wirklichen Sinn. Sekundärindizes sind gut für bekannte Zugriffsmuster, bei denen man sich darauf verlassen kann, dass die relevanten Filter vorhanden sind. Wenn wir möchten, dass der Besitzer unseres Fitnessstudios nach einer Vielzahl von Attributen filtern kann, die alle optional sind, müssten wir eine große Anzahl von Indizes erstellen, damit dies funktioniert.

Wir haben bereits über die möglichen Nachteile von Abfrageplanern gesprochen, aber Abfrageplaner haben auch Vorteile. Sie ermöglichen nicht nur flexiblere Abfragen, sondern können auch Dinge wie Indexschnittpunkte ausführen, um beim Erstellen dieser Abfragen Teilergebnisse aus mehreren Indizes zu betrachten. Sie können dasselbe mit DynamoDB tun, aber dies führt zu viel Hin und Her mit Ihrer Anwendung und einer komplexen Anwendungslogik, die Sie herausfinden müssen.

Wenn ich auf diese Art von Problemen stoße, suche ich im Allgemeinen nach einem Tool, das für diesen Anwendungsfall besser geeignet ist. Rockset und Elasticsearch sind hier meine bevorzugten Empfehlungen für die Bereitstellung einer flexiblen, sekundären Index-ähnlichen Filterung Ihres Datensatzes.

Abschluss

In diesem Beitrag haben wir etwas über sekundäre Indizes in DynamoDB gelernt. Zuerst haben wir uns einige konzeptionelle Aspekte angesehen, um zu verstehen, wie DynamoDB funktioniert und warum sekundäre Indizes benötigt werden. Dann haben wir einige praktische Tipps durchgesehen, um zu verstehen, wie sekundäre Indizes effektiv eingesetzt werden können und um ihre spezifischen Eigenheiten kennenzulernen. Schließlich haben wir uns angesehen, wie man über sekundäre Indizes nachdenken sollte, um zu sehen, wann man andere Ansätze verwenden sollte.

Sekundärindizes sind ein leistungsstarkes Tool in Ihrem DynamoDB-Werkzeugkasten, aber kein Allheilmittel. Wie bei allen DynamoDB-Datenmodellen sollten Sie Ihre Zugriffsmuster sorgfältig durchdenken und die Kosten berechnen, bevor Sie loslegen.

Weitere Informationen zur Verwendung von Rockset für sekundärindexähnliche Filterung finden Sie im Blog „DynamoDB-Filterung und Aggregationsabfragen mit SQL auf Rockset“ von Alex DeBrie.