Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Verwenden globaler sekundärer Indizes für materialisierte Aggregationsabfragen in DynamoDB

Die Wartung von Aggregationen, die beinahe in Echtzeit ausgeführt werden, und Schlüsselmetriken für Daten, die sich schnell verändern, wird zunehmend wichtiger für Unternehmen, um schnell Entscheidungen treffen zu können. Beispielsweise möchte eine Musikbibliothek ihre am häufigsten heruntergeladenen Songs nahezu in Echtzeit präsentieren, oder eine E-Commerce-Plattform muss möglicherweise Trendprodukte nach Kategorien anzeigen.

Da DynamoDB keine systemeigenen Aggregationsoperationen wie SUM oder COUNT elementübergreifend unterstützt, würde die Berechnung dieser Werte zum Zeitpunkt des Lesens das Scannen einer großen Anzahl von Elementen erfordern — was langsam und teuer sein kann. Stattdessen können Sie Aggregationen vorab berechnen, wenn sich Daten ändern, und die Ergebnisse als reguläre Elemente in Ihrer Tabelle speichern. Dieses Muster wird als materialisierte Aggregation bezeichnet.

Beispielszenario und Zugriffsmuster

Stellen Sie sich eine Musikbibliotheksanwendung mit den folgenden Anforderungen vor:

Bei dieser Größenordnung kann es teuer sein, die Anzahl der Downloads zum Zeitpunkt des Lesens zu berechnen, indem alle Download-Datensätze gescannt werden. Stattdessen können Sie eine fortlaufende Zählung beibehalten, die bei jedem Download aktualisiert wird, und diese so speichern, dass effiziente Abfragen unterstützt werden.

Warum Aggregationen vorab berechnen

Es gibt verschiedene Ansätze zur Berechnung von Aggregationen. In der folgenden Tabelle werden gängige Alternativen verglichen und erklärt, warum die materialisierte Aggregation in DynamoDB für diese Art von Anwendungsfall oft am besten geeignet ist.

Der Ansatz der materialisierten Aggregation hält den Schreibpfad einfach (zeichnet einfach den Download auf), verlagert die Aggregation in einen asynchronen Prozess und speichert das Ergebnis in DynamoDB, wo es mit einer Latenz im einstelligen Millisekundenbereich abgefragt werden kann.

Tabellendesign

Dieser Entwurf verwendet eine einzelne Tabelle mit zwei Elementtypen, die denselben Partitionsschlüssel () verwenden, aber unterschiedliche Sortierschlüsselmuster verwenden, um zwischen ihnen zu unterscheiden: songID

Nur die monatlichen Aggregationselemente enthalten das Month Attribut. Diese Unterscheidung ist wichtig für das später beschriebene, spärliche GSI-Design.

Das folgende Diagramm zeigt das Tabellenlayout mit beiden Elementtypen:

Aggregationspipeline mit Streams und AWS Lambda

Die Aggregationspipeline funktioniert wie folgt:

Die Lambda-Funktion verwendet einen UpdateItem Aufruf mit einem ADD Ausdruck, um die Anzahl der Downloads atomar zu erhöhen. Dadurch werden Rennbedingungen vermieden read-modify-write:

import boto3

dynamodb = boto3.resource('dynamodb')
table = dynamodb.Table('MusicLibrary')

def handler(event, context):
    for record in event['Records']:
        if record['eventName'] == 'INSERT':
            new_image = record['dynamodb']['NewImage']
            song_id = new_image['songID']['S']
            # Derive the month from the download timestamp
            timestamp = new_image['Timestamp']['S']
            month = timestamp[:7]  # Extract YYYY-MM

            table.update_item(
                Key={
                    'songID': song_id,
                    'SK': month
                },
                UpdateExpression='ADD DownloadCount :inc SET #m = :month',
                ExpressionAttributeNames={
                    '#m': 'Month'
                },
                ExpressionAttributeValues={
                    ':inc': 1,
                    ':month': month
                }
            )

Sparsamer GSI-Entwurf

Um die aggregierten Ergebnisse effizient abzufragen, erstellen Sie einen globalen sekundären Index mit dem folgenden Schlüsselschema:

Dieser globale Index ist spärlich, da das Attribut nur in den monatlichen Aggregationselementen enthalten ist. Month Die einzelnen Download-Datensätze haben dieses Attribut nicht und werden daher automatisch aus dem Index ausgeschlossen. Das bedeutet, dass der globale Index nur die vorberechneten Aggregationselemente enthält — einen kleinen Teil der gesamten Elemente in der Tabelle.

Ein spärlicher globaler Index bietet zwei wichtige Vorteile:

Weitere Hinweise zur Funktionsweise von Indizes mit geringer Dichte finden Sie unter. Verwendung von Sparse Indexes

Den GSI abfragen

Wenn der globale Index mit geringer Dichte eingerichtet ist, können Sie verschiedene Arten von Abfragen effizient beantworten:

Holen Sie sich den Song, der in einem bestimmten Monat am häufigsten heruntergeladen wurde:

aws dynamodb query \
    --table-name "MusicLibrary" \
    --index-name "MonthDownloadsIndex" \
    --key-condition-expression "#m = :month" \
    --expression-attribute-names '{"#m": "Month"}' \
    --expression-attribute-values '{":month": {"S": "2018-01"}}' \
    --scan-index-forward false \
    --limit 1

Bei Einstellung ScanIndexForward auf werden die Ergebnisse DownloadCount in absteigender Reihenfolge false sortiert und es wird nur der Titel Limit=1 zurückgegeben, der am häufigsten gespielt wird.

Ruft die 10 besten Songs für einen bestimmten Monat ab:

aws dynamodb query \
    --table-name "MusicLibrary" \
    --index-name "MonthDownloadsIndex" \
    --key-condition-expression "#m = :month" \
    --expression-attribute-names '{"#m": "Month"}' \
    --expression-attribute-values '{":month": {"S": "2018-01"}}' \
    --scan-index-forward false \
    --limit 10

Erhalte alle Songs, die in einem bestimmten Monat heruntergeladen wurden (sortiert nach Anzahl der Downloads):

aws dynamodb query \
    --table-name "MusicLibrary" \
    --index-name "MonthDownloadsIndex" \
    --key-condition-expression "#m = :month" \
    --expression-attribute-names '{"#m": "Month"}' \
    --expression-attribute-values '{":month": {"S": "2018-01"}}' \
    --scan-index-forward false

Überlegungen

Beachten Sie bei der Implementierung dieses Musters Folgendes: