Uso de índices secundarios globales para consultas de agregación materializadas en DynamoDB

Mantener métricas clave y agregaciones casi en tiempo real sobre datos que cambian rápidamente es algo que las compañías cada vez valoran más, ya que les permite tomar decisiones rápidas. Por ejemplo, es posible que una biblioteca de música quiera mostrar sus canciones más descargadas casi en tiempo real o que una plataforma de comercio electrónico necesite mostrar los productos más populares por categoría.

Como DynamoDB no admite de forma nativa operaciones de agregación como SUM o COUNT entre elementos, el cálculo de estos valores en tiempo de lectura requeriría analizar un gran número de elementos, lo que puede resultar lento y caro. En su lugar, puede calcular previamente las agregaciones a medida que cambian los datos y almacenar los resultados como elementos normales de la tabla. Este patrón se llama agregación materializada.

Ejemplo de escenario y patrones de acceso

Considere una aplicación de biblioteca de música con los siguientes requisitos:

Calcular los recuentos de descargas en tiempo de lectura analizando todos los registros de descargas puede resultar caro a esta escala. En su lugar, puede mantener un recuento continuo que se actualice a medida que se produzca cada descarga y almacenarlo de forma que permita realizar consultas de forma eficaz.

Por qué calcular previamente las agregaciones

Existen varios enfoques para calcular las agregaciones. En la siguiente tabla, se comparan las alternativas más comunes y se explica por qué la agregación materializada en DynamoDB suele ser la más adecuada para este tipo de casos de uso.

El enfoque de agregación materializada simplifica la ruta de escritura (basta con registrar la descarga), transfiere la agregación a un proceso asíncrono y almacena el resultado en DynamoDB, donde se puede consultar con una latencia de milisegundos de un solo dígito.

Diseño de tabla

En este diseño, se utiliza una sola tabla con dos tipos de elementos que comparten la misma clave de partición (songID) pero utilizan diferentes patrones de claves de clasificación entre ellos:

Solo los elementos de agregación mensual contienen el atributo Month. Esta distinción es importante para el diseño de GSI disperso que se describe más adelante.

En el siguiente diagrama se muestra el diseño de la tabla con ambos tipos de elementos:

Canalización de agregación con Streams y AWS Lambda

La canalización de agregación funciona de la siguiente manera:

La función de Lambda usa una llamada de UpdateItem con una expresión ADD para incrementar de forma atómica el recuento de descargas. Esto evita las condiciones de carrera de lectura-modificación-escritura:

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

Diseño de GSI disperso

Para consultar de manera eficiente los resultados agregados, cree un índice secundario global con el siguiente esquema de claves:

Este GSI es disperso porque solo los elementos de agregación mensuales contienen el atributo Month. Los registros de descarga individuales no tienen este atributo, por lo que se excluyen automáticamente del índice. Esto significa que GSI contiene solo los elementos de agregación calculados previamente, es decir, una pequeña fracción del total de elementos de la tabla.

Un GSI disperso ofrece dos beneficios clave:

Para obtener más información sobre cómo funcionan los índices dispersos, consulte Sacar partido de los índices dispersos.

Consulta del GSI

Con el GSI disperso establecido, puede responder de manera eficiente a varios tipos de consultas:

Obtenga la canción más descargada en un mes determinado:

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

La configuración de ScanIndexForward en false ordena los resultados por DownloadCount en orden descendente y Limit=1 devuelve solo la canción principal.

Obtenga las 10 mejores canciones de un mes determinado:

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

Obtenga todas las canciones descargadas en un mes determinado (ordenadas por número de descargas):

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

Consideraciones

Tenga en cuenta lo siguiente al implementar este patrón: