Unterschied zwischen lokalen und globalen Indizes in DynamoDB

Ich bin neugierig auf diese beiden Sekundärindizes und Unterschiede zwischen ihnen. Es ist schwer vorstellbar, wie das aussieht. Und ich denke, das wird mehr Menschen helfen als nur mir.

Lokale Sekundärindizes basieren weiterhin auf dem ursprünglichen Hash-Schlüssel. Wenn Sie eine Tabelle mit Hash + Bereich angeben, stellen Sie sich den LSI als Hash + Bereich1, Hash + Bereich2 .. Hash + Bereich6 vor. Sie erhalten 5 weitere Bereichsattribute zum Abfragen. Außerdem gibt es nur einen bereitgestellten Durchsatz.

Globale Sekundärindizes definieren ein neues Paradigma - verschiedene Hash- / Bereichsschlüssel pro Index.
Dies bricht die ursprüngliche Verwendung eines Hash-Schlüssels pro Tabelle. Aus diesem Grund müssen Sie bei der Definition von GSI einen bereitgestellten Durchsatz pro Index hinzufügen und dafür bezahlen.

Weitere Informationen zu den Unterschieden finden Sie in der GSI-Ankündigung

Hier ist die formale Definition aus der Dokumentation:

Globaler Sekundärindex - Ein Index mit einem Hash und einem Bereichsschlüssel, die sich von denen in der Tabelle unterscheiden können. Ein globaler Sekundärindex wird als "global" betrachtet, da Abfragen im Index alle Daten in einer Tabelle über alle Partitionen hinweg umfassen können.

Lokaler Sekundärindex - Ein Index, der denselben Hash-Schlüssel wie die Tabelle, jedoch einen anderen Bereichsschlüssel hat. Ein lokaler Sekundärindex ist "lokal" in dem Sinne, dass jede Partition eines lokalen Sekundärindex auf eine Tabellenpartition mit demselben Hash-Schlüssel beschränkt ist.

Die Unterschiede gehen jedoch weit über die Möglichkeiten der Schlüsseldefinitionen hinaus. Nachfolgend finden Sie einige wichtige Faktoren, die sich direkt auf die Kosten und den Aufwand für die Pflege der Indizes auswirken:

• Durchsatz:

Lokale Sekundärindizes verbrauchen den Durchsatz aus der Tabelle. Wenn Sie Datensätze über den lokalen Index abfragen, verbraucht der Vorgang Lesekapazitätseinheiten aus der Tabelle. Wenn Sie eine Schreiboperation (Erstellen, Aktualisieren, Löschen) in einer Tabelle mit einem lokalen Index ausführen, gibt es zwei Schreiboperationen, eine für die Tabelle und eine für den Index. Beide Operationen verbrauchen Schreibkapazitätseinheiten aus der Tabelle.

Globale Sekundärindizes haben ihren eigenen bereitgestellten Durchsatz. Wenn Sie den Index abfragen, verbraucht die Operation Lesekapazität aus dem Index. Wenn Sie eine Schreiboperation (Erstellen, Aktualisieren, Löschen) in einer Tabelle mit einem globalen Index ausführen, gibt es zwei Schreiboperationen, eine für die Tabelle und eine für den Index *.

* Achten Sie beim Definieren des bereitgestellten Durchsatzes für den globalen Sekundärindex besonders auf die folgenden Anforderungen:

Damit ein Tabellenschreiben erfolgreich ist, müssen die bereitgestellten Durchsatzeinstellungen für die Tabelle und alle ihre globalen Sekundärindizes über genügend Schreibkapazität verfügen, um das Schreiben aufzunehmen. Andernfalls wird das Schreiben in die Tabelle gedrosselt.

• Management :

Lokale Sekundärindizes können nur erstellt werden, wenn Sie die Tabelle erstellen. Es gibt keine Möglichkeit, einer vorhandenen Tabelle einen lokalen Sekundärindex hinzuzufügen. Auch wenn Sie den Index erstellt haben, können Sie ihn nicht mehr löschen.

Globale Sekundärindizes können erstellt werden, wenn Sie die Tabelle erstellen und zu einer vorhandenen Tabelle hinzufügen. Das Löschen eines vorhandenen globalen Sekundärindex ist ebenfalls zulässig.

• Lesekonsistenz:

Lokale Sekundärindizes unterstützen eine eventuelle oder starke Konsistenz, während der globale Sekundärindex nur eine eventuelle Konsistenz unterstützt.

• Projektion:

Lokale Sekundärindizes ermöglichen das Abrufen von Attributen, die nicht auf den Index projiziert werden (allerdings mit zusätzlichen Kosten: Leistung und verbrauchte Kapazitätseinheiten). Mit Global Secondary Index können Sie nur die auf den Index projizierten Attribute abrufen.

Besondere Überlegungen zur Eindeutigkeit der für Sekundärindizes definierten Schlüssel:

In einem lokalen Sekundärindex muss der Bereichsschlüsselwert für einen bestimmten Hash-Schlüsselwert NICHT eindeutig sein. Gleiches gilt für globale Sekundärindizes. Die Schlüsselwerte (Hash und Bereich) müssen NICHT eindeutig sein.

Quelle: http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/SecondaryIndexes.html

Dies sind die möglichen Suchvorgänge nach Index:

• Von Hash
• Mit Hash + Range
• Nach Hash + Local Index
• Nach globalem Index
• Nach globalem Index + Bereichsindex

Hash- und Bereichsindizes einer Tabelle: Dies sind die üblichen Indizes früherer Versionen des Amazon AWS SDK.

Globale und lokale Indizes: Hierbei handelt es sich um zusätzliche Indizes, die zusätzlich zu den vorhandenen Hash- und Bereichsindizes der Tabelle für eine Tabelle erstellt wurden. Der globale Index ähnelt einem Hash. Entfernungs - Index verhält sich ähnlich wie der Entfernungs - Index mit dem Hash - Wert von der Tabelle verwendet. In Ihrem Entitätsmodell in Ihrem Code muss der Getter folgendermaßen kommentiert werden:

• Für globale Indizes:

  @DynamoDBIndexHashKey(globalSecondaryIndexName = INDEX_GLOBAL_RANGE_US_TS)
  @DynamoDBAttribute(attributeName = PROPERTY_USER)
  public String getUser() {
      return user;
  }
  

• Für den dem globalen Index zugeordneten Bereichsindex:

  @DynamoDBIndexRangeKey(globalSecondaryIndexName = INDEX_GLOBAL_RANGE_US_TS)
  @DynamoDBAttribute(attributeName = PROPERTY_TIMESTAMP)
  public String getTimestamp() {
      return timestamp;
  }
  

Wenn Sie eine Tabelle anhand eines globalen Index lesen, muss es sich außerdem um einen eventuellen Lesevorgang (nicht um einen konsistenten Lesevorgang) handeln:

queryExpression.setConsistentRead(false);

Eine Möglichkeit, es auszudrücken, ist folgende:

LSI - Ermöglicht es Ihnen, eine Abfrage für einen einzelnen Hash-Schlüssel durchzuführen, während Sie mehrere verschiedene Attribute verwenden, um die Abfrage zu "filtern" oder einzuschränken.

GSI - Ermöglicht das Ausführen von Abfragen für mehrere Hash-Keys in einer Tabelle, kostet jedoch dadurch einen zusätzlichen Durchsatz.

Im Folgenden finden Sie eine ausführlichere Aufschlüsselung der Tabellentypen und ihrer Funktionsweise:

Nur Hash

Wie Sie wahrscheinlich schon wissen; Ein Hash-Schlüssel selbst muss eindeutig sein, da das Schreiben in einen bereits vorhandenen Hash-Schlüssel die vorhandenen Daten überschreibt.

Hash + Range

Mit einem Hash-Key + Range-Key können Sie mehrere Hash-Keys verwenden, die gleich sind, sofern sie einen anderen Range-Key haben. Wenn Sie in diesem Fall in einen bereits vorhandenen Hash-Schlüssel schreiben, aber einen Bereichsschlüssel verwenden, der von diesem Hash-Schlüssel noch nicht verwendet wird, wird ein neues Element erstellt, während ein Element mit derselben Hash + Range-Kombination verwendet wird bereits vorhanden, überschreibt es den passenden Artikel.

Eine andere Art, sich das vorzustellen, ist wie eine Datei mit einem Format. Sie können eine Datei mit demselben Namen (Hash) wie eine andere im selben Ordner (Tabelle) haben, sofern ihr Format (Bereich) unterschiedlich ist. Ebenso können Sie mehrere Dateien desselben Formats haben, solange deren Name unterschiedlich ist.

LSI

Ein LSI ist im Grunde dasselbe wie ein Hash-Key + Range-Key und folgt beim Erstellen von Elementen denselben Regeln wie er, außer dass Sie auch Werte für die LSIs angeben müssen. Sie können nicht leer / null gelassen werden.

Zu sagen, ein LSI sei "Range-Key 2", ist nicht ganz richtig, da Sie (unter Verwendung meiner Datei- und Formatanalogie von früher) keine Datei mit dem Namen: file.format.lsiund haben können file.format.lsi2. Sie können jedoch file.format.lsiund file.format2.lsioder file.format.lsiund und haben file2.format.lsi.

Grundsätzlich ist ein LSI nur ein "Filter-Key", kein tatsächlicher Range-Key. Ihre Basis-Hash- und Range-Wertekombination muss weiterhin eindeutig sein, während die LSI-Werte überhaupt nicht eindeutig sein müssen. Eine einfachere Möglichkeit, dies zu betrachten, besteht darin, sich das LSI als Daten in den Dateien vorzustellen. Sie können Code schreiben, der alle Dateien mit dem Namen "PROJECT101" findet, unabhängig von deren Namen fileFormat, und dann die darin enthaltenen Daten liest, um zu bestimmen, was in der Abfrage enthalten sein soll und was weggelassen wird. Dies ist im Grunde die Funktionsweise von LSI (nur ohne den zusätzlichen Aufwand beim Öffnen der Datei zum Lesen des Inhalts).

GSI

Für GSI erstellen Sie im Wesentlichen eine andere Tabelle für jede GSI, ohne jedoch mehrere separate Tabellen verwalten zu müssen, die Daten zwischen ihnen spiegeln. Deshalb kosten sie mehr Durchsatz.

Für eine GSI können Sie also fileNameals Basis-Hash-Key und fileFormatals Basis-Range-Key angeben . Sie können dann eine GSI angeben, die einen Hash-Key von fileName2und einen Range-Key von hat fileFormat2. Sie können dann entweder abfragen fileNameoder fileName2wenn Sie möchten, im Gegensatz zu LSI, wo Sie nur abfragen können fileName.

Die Hauptvorteile sind, dass Sie nur eine Tabelle anstelle von 2 verwalten müssen und jedes Mal, wenn Sie entweder in den primären Hash / Bereich oder in den GSI-Hash / Bereich schreiben, werden auch die anderen automatisch aktualisiert. Sie können also nicht "vergessen", die anderen Tabellen zu aktualisieren, wie dies bei einem Setup mit mehreren Tabellen der Fall ist. Es besteht auch keine Möglichkeit, dass die Verbindung nach dem Aktualisieren einer und vor dem Aktualisieren der anderen unterbrochen wird, wie dies beim Setup mit mehreren Tabellen der Fall ist.

Zusätzlich kann eine GSI die Basis-Hash / Range-Kombination "überlappen". Wenn Sie also eine Tabelle mit fileNameund fileFormatals Basis-Hash / Range filePriorityund fileNameals GSI erstellen möchten, können Sie dies tun.

Schließlich muss eine GSI-Hash + Range-Kombination nicht eindeutig sein, während die Basis-Hash + Range-Kombination eindeutig sein muss. Dies ist mit einem Dual / Multi-Table-Setup nicht möglich, aber mit GSI. Daher MÜSSEN Sie beim Aktualisieren Werte sowohl für den Basis- als auch für den GSI-Hash + -Bereich angeben. Keiner dieser Werte kann leer / null sein.

Eine andere Möglichkeit zur Erklärung: Mit LSI können Sie zusätzliche Abfragen für Elemente mit demselben Hash-Schlüssel durchführen. GSI hilft Ihnen dabei, ähnliche Abfragen für Elemente "über die Tabelle" durchzuführen. Also sehr nützlich.

Wenn Sie eine Benutzerprofiltabelle haben: eindeutige ID, Name, E-Mail. Hier, wenn Sie die Tabelle nach Name, E-Mail abfragbar machen müssen - dann ist die einzige Möglichkeit, sie GSI zu machen (LSI hilft nicht)

Diese Dokumentation gibt eine ziemlich gute Erklärung:

https://aws.amazon.com/blogs/aws/now-available-global-secondary-indexes-for-amazon-dynamodb/

Ich konnte diese Frage nicht kommentieren, aber was ist besser in Bezug auf die Schreib- und Leseleistung:

(Lokaler Index mit einem Lese- und Schreibdurchsatz von 100) oder (globaler Index mit einem Lese- / Schreibdurchsatz von 50 zusammen mit einem Lese- / Schreibdurchsatz von 50?)

Ich benötige keinen separaten Partitionsschlüssel für meinen Anwendungsfall, daher sollte der lokale Index für die erforderliche Funktionalität ausreichen.

GSIs können nicht für konsistente Lesevorgänge verwendet werden.

LSIs können für konsistente Lesevorgänge verwendet werden, begrenzen jedoch Ihre Partitionsgröße auf 10 GB und können nur bei der Tabellenerstellung erstellt werden.