Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Utilisation d’index secondaire globaux pour les requêtes de regroupement matérialisé dans DynamoDB

La gestion des regroupements et des métriques clés presque en temps réel sur des données qui changent rapidement s’avère de plus en plus utile que les entreprises puissent prendre des décisions rapides. Par exemple, une bibliothèque musicale peut vouloir présenter ses chansons les plus téléchargées en temps quasi réel, ou une plateforme de commerce électronique peut avoir besoin d'afficher les produits tendance par catégorie.

DynamoDB ne prenant pas en charge de manière native les opérations d'agrégation SUM telles que COUNT ou entre des éléments, le calcul de ces valeurs au moment de la lecture nécessiterait de scanner un grand nombre d'éléments, ce qui peut être lent et coûteux. Au lieu de cela, vous pouvez précalculer les agrégations à mesure que les données changent et stocker les résultats sous forme d'éléments réguliers dans votre tableau. Ce modèle est appelé agrégation matérialisée.

Exemple de scénario et de modèles d'accès

Envisagez une application de bibliothèque musicale répondant aux exigences suivantes :

Calculer le nombre de téléchargements au moment de la lecture en scannant tous les enregistrements de téléchargement peut s'avérer coûteux à cette échelle. Au lieu de cela, vous pouvez maintenir un nombre cumulé qui se met à jour à chaque téléchargement et le stocker de manière à permettre des requêtes efficaces.

Pourquoi précalculer les agrégations

Il existe plusieurs approches pour calculer les agrégations. Le tableau suivant compare les alternatives les plus courantes et explique pourquoi l'agrégation matérialisée dans DynamoDB est souvent la meilleure solution pour ce type de cas d'utilisation.

L'approche d'agrégation matérialisée simplifie le chemin d'écriture (il suffit d'enregistrer le téléchargement), décharge l'agrégation vers un processus asynchrone et stocke le résultat dans DynamoDB où il peut être interrogé avec une latence d'un chiffre en millisecondes.

Conception d’une table

Cette conception utilise une seule table avec deux types d'éléments qui partagent la même clé de partition (songID) mais utilisent des modèles de clés de tri différents pour les distinguer :

Seuls les éléments d'agrégation mensuels contiennent l'Monthattribut. Cette distinction est importante pour le design GSI clairsemé décrit plus loin.

Le schéma suivant montre la disposition du tableau avec les deux types d'éléments :

Pipeline d'agrégation avec Streams et AWS Lambda

Le pipeline d'agrégation fonctionne comme suit :

La fonction Lambda utilise un UpdateItem appel avec une ADD expression pour incrémenter de manière atomique le nombre de téléchargements. Cela permet d'éviter les conditions de read-modify-write course :

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
                }
            )

Conception GSI clairsemée

Pour interroger efficacement les résultats agrégés, créez un index secondaire global avec le schéma de clé suivant :

Ce GSI est clairsemé car seuls les éléments d'agrégation mensuels contiennent l'Monthattribut. Les enregistrements de téléchargement individuels ne possèdent pas cet attribut, ils sont donc automatiquement exclus de l'index. Cela signifie que le GSI ne contient que les éléments d'agrégation précalculés, soit une petite fraction du total des éléments du tableau.

Un GSI clairsemé présente deux avantages essentiels :

Pour plus d'informations sur le fonctionnement des index épars, consultez. Tirer profit des index partiellement alloués

Interrogation du GSI

Avec le GSI clairsemé en place, vous pouvez répondre efficacement à plusieurs types de requêtes :

Obtenez la chanson la plus téléchargée pendant un mois donné :

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

Le paramètre ScanIndexForward permet de false trier les résultats par DownloadCount ordre décroissant et de Limit=1 renvoyer uniquement le titre le plus populaire.

Découvrez les 10 meilleures chansons d'un mois donné :

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

Téléchargez toutes les chansons au cours d'un mois donné (triées par nombre de téléchargements) :

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

Considérations

Tenez compte des points suivants lors de la mise en œuvre de ce modèle :