Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Utilizzo di indici secondari globali per query di aggregazione materializzate in DynamoDB

Il mantenimento di aggregazioni quasi in tempo reale e parametri chiave oltre a dati in rapida evoluzione sta acquisendo sempre più valore per permettere alle aziende di prendere decisioni in maniera veloce. Ad esempio, una libreria musicale potrebbe voler mostrare i brani più scaricati quasi in tempo reale, oppure una piattaforma di e-commerce potrebbe dover mostrare i prodotti di tendenza per categoria.

Poiché DynamoDB non supporta in modo nativo operazioni di aggregazione simili SUM o COUNT tra elementi, il calcolo di questi valori in fase di lettura richiederebbe la scansione di un gran numero di elementi, operazione che potrebbe essere lenta e costosa. Invece, puoi precalcolare le aggregazioni man mano che i dati cambiano e memorizzare i risultati come elementi normali nella tabella. Questo modello è chiamato aggregazione materializzata.

Scenario di esempio e modelli di accesso

Considerate un'applicazione di libreria musicale con i seguenti requisiti:

Calcolare il conteggio dei download in fase di lettura mediante la scansione di tutti i record di download può essere costoso su questa scala. È invece possibile mantenere un conteggio corrente che si aggiorna a ogni download e archiviarlo in modo da supportare un'interrogazione efficiente.

Perché precalcolare le aggregazioni

Esistono diversi approcci al calcolo delle aggregazioni. La tabella seguente confronta le alternative più comuni e spiega perché l'aggregazione materializzata in DynamoDB è spesso la soluzione migliore per questo tipo di caso d'uso.

L'approccio di aggregazione materializzata mantiene semplice il percorso di scrittura (basta registrare il download), trasferisce l'aggregazione in un processo asincrono e memorizza il risultato in DynamoDB dove può essere interrogato con una latenza di una cifra in millisecondi.

Progettazione di tabelle

Questo design utilizza una singola tabella con due tipi di elementi che condividono la stessa chiave di partizione () ma utilizzano modelli di chiave di ordinamento diversi per distinguerli: songID

Solo gli elementi di aggregazione mensili contengono l'Monthattributo. Questa distinzione è importante per il design GSI sparso descritto più avanti.

Il diagramma seguente mostra il layout della tabella con entrambi i tipi di elementi:

Pipeline di aggregazione con Streams e AWS Lambda

La pipeline di aggregazione funziona come segue:

La funzione Lambda utilizza una UpdateItem chiamata con un'ADDespressione per incrementare atomicamente il numero di download. Questo evita le condizioni di gara tra lettura, modifica e scrittura:

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

Design GSI sparso

Per interrogare in modo efficiente i risultati aggregati, crea un indice secondario globale con il seguente schema chiave:

Questo GSI è scarso perché solo gli elementi di aggregazione mensili contengono l'attributo. Month I singoli record di download non hanno questo attributo, quindi vengono automaticamente esclusi dall'indice. Ciò significa che il GSI contiene solo gli elementi di aggregazione precalcolati, una piccola parte degli elementi totali della tabella.

Un GSI sparso offre due vantaggi principali:

Per ulteriori informazioni sul funzionamento degli indici sparsi, vedere. Trai vantaggio degli indici di tipo sparse

Interrogazione del GSI

Con il GSI sparso, puoi rispondere in modo efficiente a diversi tipi di domande:

Ottieni la canzone più scaricata in un determinato mese:

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

L'impostazione ScanIndexForward su false ordina i risultati DownloadCount in ordine decrescente e Limit=1 restituisce solo il brano principale.

Ottieni le 10 migliori canzoni di un determinato mese:

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

Ottieni tutti i brani scaricati in un determinato mese (ordinati per numero di download):

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

Considerazioni

Tieni presente quanto segue quando implementi questo modello: