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 nativamente operazioni di aggregazione SUM simili COUNT o tra elementi, il calcolo di questi valori in fase di lettura richiederebbe la scansione di un gran numero di elementi, il che può essere lento e costoso. È invece possibile precalcolare le aggregazioni man mano che i dati cambiano e archiviare i risultati come normali elementi della tabella. Questo modello è chiamato aggregazione materializzata.

Scenario di esempio e modelli di accesso

Prendi in considerazione 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 costante che si aggiorna a ogni download e archiviarlo in un modo che supporti l'esecuzione di query efficienti.

Perché precalcolare le aggregazioni

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

L'approccio di aggregazione materializzata semplifica il percorso di scrittura (basta registrare il download), trasferisce l'aggregazione su un processo asincrono e archivia il risultato in DynamoDB dove può essere interrogato con una latenza di un millisecondo.

Progettazione di tabelle

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

Solo gli elementi di aggregazione mensili contengono l'Monthattributo. Questa distinzione è importante per la progettazione sparsa del GSI descritta 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. In questo modo si read-modify-write evitano le condizioni di gara:

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 frazione del totale degli elementi della tabella.

Un GSI scarso offre due vantaggi principali:

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

Interrogazione del GSI

Con un GSI sparso, è possibile 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

Se ScanIndexForward si imposta su, false i risultati vengono ordinati DownloadCount in ordine decrescente e viene Limit=1 restituito solo il brano migliore.

Visualizza 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

Scarica tutti i brani 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: