Allgemeine Richtlinien für sekundäre Indexe in DynamoDB

Amazon DynamoDB unterstützt zwei Arten sekundärer Indexe:

• Globaler sekundärer Index (GSI) – Dieser Index verfügt über einen Partitionsschlüssel und einen Sortierschlüssel, die nicht mit denen der Basistabelle übereinstimmen müssen. Ein globaler sekundärer Index wird als „global“ betrachtet, da Indexabfragen partitionsübergreifend alle Daten in der Basistabelle umfassen können. Ein globaler sekundärer Index unterliegt hinsichtlich seiner Größe keinen Einschränkungen und besitzt eigene Durchsatzeinstellungen für Lese- und Schreibaktivitäten, die von denen der übergeordneten Tabelle unabhängig sind.

• Lokaler sekundärer Index (LSI) – Dieser Index weist denselben Partitionsschlüssel wie die Basistabelle auf, hat aber einen anderen Sortierschlüssel. Ein lokaler sekundärer Index wird als „lokal“ betrachtet, da jede Partition eines lokalen sekundären Index auf die Basistabellenpartition bezogen ist, die denselben Partitionsschlüsselwert besitzt. Daher kann die Gesamtgröße der indizierten Elemente für jeden einzelnen Partitionsschlüsselwert 10 GB nicht überschreiten. Darüber hinaus besitzen lokale sekundäre Indexe die gleichen Durchsatzeinstellungen für Lese- und Schreibaktivitäten wie die Tabelle, die indiziert wird.

Jede Tabelle in DynamoDB kann bis zu 20 globale sekundäre Indexe (Standardkontingent) und 5 lokale sekundäre Indexe enthalten.

Globale Sekundärindizes sind oft nützlicher als lokale Sekundärindizes. Die Entscheidung, welcher Indextyp verwendet werden soll, hängt auch von den Anforderungen Ihrer Anwendung ab. Einen Vergleich zwischen globalen Sekundärindizes und lokalen Sekundärindizes sowie weitere Informationen zur Auswahl zwischen diesen Indizes finden Sie unter. Verbessern des Datenzugriffs mit sekundären Indizes

Im Folgenden werden einige allgemeine Grundsätze und Designmuster beschrieben, die Sie beim Erstellen von Indizes in DynamoDB beachten sollten:

Effiziente Verwendung von Indizes

Begrenzen Sie die Zahl der Indizes auf ein Minimum. Erstellen Sie keine sekundären Indizes für Attribute, die Sie nicht oft abfragen. Selten verwendete Indizes führen zu höheren Speicher- und I/O-Kosten, ohne die Anwendungsleistung zu verbessern.

Sorgfältige Auswahl von Projektionen

Da sekundäre Indizes Speicher- und Durchsatzkapazitäten verbrauchen, sollten Sie dafür sorgen, dass die Indizes möglichst klein sind. Je kleiner der Index ist, desto größer ist auch der Leistungsvorteil im Vergleich zur Abfrage der vollständigen Tabelle. Wenn Ihre Abfragen in der Regel nur einen kleinen Teil der Attribute zurückgeben und die Gesamtgröße dieser Attribute sehr viel kleiner als das gesamte Element ist, sollten Sie nur die Attribute projizieren, die Sie regelmäßig anfordern.

Wenn Sie von davon ausgehen, dass eine Tabelle sehr viel mehr Schreibaktivitäten als Leseaktivitäten unterliegt, befolgen Sie diese bewährten Methoden:

• Ziehen Sie die Projizierung einer kleineren Anzahl von Attributen in Betracht, um die Größe der Elemente, die in den Index geschrieben werden, zu minimieren. Dies gilt jedoch nur, wenn die Größe der projizierten Attribute andernfalls die Größe einer einzelnen Schreibkapazitätseinheit (1 KB) überschreiten würde. Wenn z. B. die Größe eines Indexeintrags nur 200 Byte beträgt, rundet DynamoDB diesen Wert auf 1 KB ab. Mit anderen Worten: Solange die Indexelemente klein sind, können Sie mehr Attribute ohne Zusatzkosten projizieren.

• Vermeiden Sie die Projizierung von Attributen, von denen Sie wissen, dass sie selten in Abfragen benötigt werden. Bei jeder Aktualisierung eines Attributs, das in einem Index projiziert ist, fallen auch zusätzliche Kosten für die Aktualisierung des Index an. Sie können nach wie vor die nicht projizierten Attribute in einer Query zu höheren Durchsatzkosten abrufen. Die Kosten für die Abfrage sind jedoch möglicherweise deutlich niedriger als die Kosten für die häufige Aktualisierung des Index.

• Geben Sie ALL nur an, wenn Ihre Abfragen das gesamte Tabellenelement sortiert nach einem anderen Sortierschlüssel zurückgeben sollen. Die Projizierung aller Attribute beseitigt die Notwendigkeit des Abrufens von Tabellen, verdoppelt jedoch in den meisten Fällen die Kosten für Speicherung und Schreibaktivitäten.

Stellen Sie ein Gleichgewicht zwischen der Notwendigkeit her, die Indizes so klein wie möglich zu halten, und der Notwendigkeit, die Zahl der Abrufe auf ein Minimum zu begrenzen.

Optimierung häufiger Abfragen zur Vermeidung von Abrufen

Um Abfragen so schnell wie möglich mit der geringstmöglichen Latenz auszuführen, sollten Sie alle Attribute projizieren, die von diesen Abfragen voraussichtlich zurückgegeben werden. Wenn Sie einen lokalen sekundären Index nach nicht projizierten Attributen abfragen, ruft DynamoDB diese Attribute automatisch aus der Tabelle ab. Dies erfordert, dass das gesamte Element aus der Tabelle gelesen wird. Dieser Vorgang führt zu Latenz und zu zusätzlichen E/A-Vorgängen, die Sie vermeiden können.

Beachten Sie, dass in vielen Fällen aus „gelegentlichen“ Abfragen „wesentliche“ Abfragen werden. Wenn es Attribute gibt, die Sie nicht projizieren möchten, da Sie davon ausgehen, dass sie nur gelegentlich abgefragt werden, sollten Sie sich überlegen, ob sich die Umstände vielleicht ändern könnten und Sie es daher bedauern könnten, dass Sie diese Attribute nicht projiziert haben.

Weitere Informationen zum Abrufen von Tabellen finden Sie unter Überlegungen im Hinblick auf die bereitgestellte Durchsatzkapazität für lokale sekundäre Indizes.

Berücksichtigung der Größenbegrenzungen von Elementauflistungen beim Erstellen lokaler sekundärer Indizes

Eine Elementauflistung besteht aus allen Elementen in einer Tabelle und ihren lokalen sekundären Indizes, die denselben Partitionsschlüssel haben. Elementauflistungen dürfen 10 GB nicht überschreiten. Daher ist es möglich, dass es für einen bestimmten Partitionsschlüsselwert keinen Platz mehr gibt.

Wenn Sie ein Tabellenelement hinzufügen oder aktualisieren, aktualisiert DynamoDB alle betroffenen lokalen sekundären Indizes. Wenn die indizierten Attribute in der Tabelle definiert sind, nimmt die Größe der lokalen sekundären Indizes ebenfalls zu.

Überlegen Sie beim Erstellen eines lokalen sekundären Index, wie viele Daten in den Index geschrieben werden und wie viele dieser Datenelemente denselben Partitionsschlüsselwert haben werden. Wenn die Summe der Tabellen- und Indexelemente für einen bestimmten Partitionsschlüsselwert 10 GB überschreiten könnte, sollten Sie überlegen, ob Sie die Erstellung des Index vermeiden sollten.

Wenn Sie die Erstellung des lokalen sekundären Index nicht vermeiden können, müssen Sie geeignete Maßnahmen ergreifen, bevor die Größeneinschränkung für die Elementauflistung überschritten wird. Es hat sich bewährt, den ReturnItemCollectionMetricsParameter beim Schreiben von Elementen zu verwenden, um die Größe von Elementsammlungen, die sich der Größenbeschränkung von 10 GB nähern, zu überwachen und darauf hinzuweisen. Eine Überschreitung der maximalen Größe für die Elementsammlung führt zu fehlgeschlagenen Schreibversuchen. Sie können die Probleme mit der Größe der Artikelsammlung verringern, indem Sie die Größe der Artikelsammlungen überwachen und Sie darauf hinweisen, bevor sie sich auf Ihre Anwendung auswirken.

Anmerkung

Ein einmal erstellter lokaler sekundärer Index kann nicht gelöscht werden.

Strategien zum Arbeiten innerhalb des Grenzwerts und zur Ergreifung von Korrekturmaßnahmen finden Sie unter Größenlimit der Elementauflistung.