Diseño del esquema de pagos periódicos en DynamoDB - Amazon DynamoDB
Caso de uso empresarialDiagrama de relaciones entre entidadesPatrones de accesoDiseño del esquemaEsquema finalNoSQL Workbench

Diseño del esquema de pagos periódicos en DynamoDB

Caso de uso empresarial de pagos periódicos

En este caso de uso se habla de utilizar DynamoDB para implementar un sistema de pagos periódicos. El modelo de datos tiene las siguientes entidades: cuentas, suscripciones y recibos. Los detalles específicos para nuestro caso de uso son los siguientes:

  • Cada cuenta puede tener varias suscripciones

  • La suscripción tiene una NextPaymentDate en la que se debe procesar el siguiente pago y una NextReminderDate en la que se envía un recordatorio por correo electrónico al cliente

  • Existe un elemento para la suscripción que se almacena y actualiza cuando se procesa el pago (el tamaño medio del elemento es de alrededor de 1 KB y el rendimiento depende del número de cuentas y suscripciones).

  • El procesador de pagos también creará un recibo como parte del proceso que se almacena en la tabla y se establece a expirar después de un periodo de tiempo mediante un atributo TTL

Diagrama de relación entre entidades de pagos periódicos

Este es el diagrama de relaciones entre entidades (ERD) que utilizaremos para el diseño del esquema del sistema de pagos periódicos.

Sistema de pagos recurrentes ERD que muestra las entidades: cuenta, suscripción y recibo.

Patrones de acceso al sistema de pagos periódicos

Estos son los patrones de acceso que tendremos en cuenta para el diseño del esquema del sistema de pagos periódicos.

  1. createSubscription

  2. createReceipt

  3. updateSubscription

  4. getDueRemindersByDate

  5. getDuePaymentsByDate

  6. getSubscriptionsByAccount

  7. getReceiptsByAccount

Diseño del esquema de pagos periódicos

Los nombres genéricos PK y SK se utilizan para atributos de clave que permiten almacenar distintos tipos de entidades en la misma tabla, como las entidades de cuenta, suscripción y recibo. En primer lugar, el usuario crea una suscripción, por la que se compromete a pagar una cantidad el mismo día cada mes a cambio de un producto. Puede elegir qué día del mes se procesa el pago. También se enviará un recordatorio antes de que se procese el pago. La aplicación funciona mediante dos trabajos por lotes que se ejecutan cada día: un trabajo por lotes envía los recordatorios que vencen ese día y el otro procesa los pagos que vencen ese día.

Paso 1: Abordar el patrón de acceso 1 (createSubscription)

El patrón de acceso 1 (createSubscription) se utiliza para crear inicialmente la suscripción y se establecen los detalles, como SKU, NextPaymentDate, NextReminderDate y PaymentDetails. En este paso se muestra el estado de la tabla para una sola cuenta con una suscripción. Puede haber varias suscripciones en la colección de elementos, por lo que se trata de una relación de uno a varios.

Diseño de tabla que muestra los detalles de la suscripción de una cuenta.

Paso 2: Abordar patrones de acceso 2 (createReceipt) y 3 (updateSubscription)

Se utiliza el patrón de acceso 2 (createReceipt) para crear el elemento de recibo. Una vez procesado el pago cada mes, el procesador de pagos volverá a escribir un recibo en la tabla base. Puede haber varios recibos en la colección de elementos, por lo que se trata de una relación de uno a varios. El procesador de pagos también actualizará el elemento de suscripción (patrón de acceso 3 [updateSubscription]) para actualizar para la NextReminderDate o la NextPaymentDate del mes siguiente.

Los detalles del recibo y el artículo de suscripción se actualizan para mostrar la siguiente fecha de recordatorio de suscripción.

Paso 3: Abordar el patrón de acceso 4 (getDueRemindersByDate)

La aplicación procesa los recordatorios de pago por lotes correspondientes al día en curso. Por lo tanto, la aplicación necesita acceder a las suscripciones en una dimensión diferente: fecha en lugar de cuenta. Este es un buen caso de uso para un índice secundario global (GSI). En este paso agregamos el índice GSI-1, que utiliza la NextReminderDate como clave de partición de GSI. No necesitamos replicar todos los elementos. Este GSI es un índice disperso y los elementos de entrada no están replicados. Tampoco necesitamos proyectar todos los atributos, solo necesitamos incluir un subconjunto de ellos. En la imagen siguiente se muestra el esquema de GSI-1 y se proporciona la información necesaria para que la aplicación envíe el correo electrónico de recordatorio.

Esquema de GSI-1 con detalles, como la dirección de correo electrónico, la aplicación debe enviar un correo electrónico de recordatorio.

Paso 4: Abordar el patrón de acceso 5 (getDuePaymentsByDate)

La aplicación procesa los pagos en lotes para el día en curso del mismo modo que lo hace con los recordatorios. Agregamos GSI-2 en este paso y utiliza la NextPaymentDate como la clave de partición de GSI. No necesitamos replicar todos los elementos. Este GSI es un índice disperso, ya que los elementos de entrada no están replicados. En la imagen siguiente se muestra el esquema de GSI-2.

Esquema de GSI-2 con detalles para procesar los pagos. NextPaymentDate es la clave de partición para GSI-2.

Paso 5: Abordar patrones de acceso 6 (getSubscriptionsByAccount) y 7 (getReceiptsByAccount)

La aplicación puede recuperar todas las suscripciones de una cuenta mediante una consulta en la tabla base que se dirige al identificador de la cuenta (el PK) y utiliza el operador de intervalo para obtener todos los elementos en los que el SK comienza por “SUB#”. La aplicación también puede utilizar la misma estructura de consulta para recuperar todos los recibos empleando un operador de intervalo para obtener todos los elementos en los que el SK comience por “REC#”. Esto nos permite satisfacer los patrones de acceso 6 (getSubscriptionsByAccount) y 7 (getReceiptsByAccount). La aplicación utiliza estos patrones de acceso para que el usuario pueda ver sus suscripciones actuales y sus recibos anteriores de los últimos seis meses. No hay ningún cambio en el esquema de la tabla en este paso y podemos ver a continuación cómo nos dirigimos solo a los elementos de suscripción en el patrón de acceso 6 (getSubscriptionsByAccount).

Resultado de la operación de consulta en la tabla base. Muestra la suscripción de una cuenta específica.

En la tabla siguiente se resumen todos los patrones de acceso y cómo los aborda el diseño del esquema:

Patrón de acceso Tabla base/GSI/LSI Operación Valor de clave de partición Valor de la clave de clasificación
createSubscription Tabla base PutItem ACC#account_id SUB#<SUBID>#SKU<SKUID>
createReceipt Tabla base PutItem ACC#account_id REC#<RecieptDate>#SKU<SKUID>
updateSubscription Tabla base UpdateItem ACC#account_id SUB#<SUBID>#SKU<SKUID>
getDueRemindersByDate GSI-1 Consultar <NextReminderDate>
getDuePaymentsByDate GSI-2 Consultar <NextPaymentDate>
getSubscriptionsByAccount Tabla base Consultar ACC#account_id SK begins_with “SUB#”
getReceiptsByAccount Tabla base Consultar ACC#account_id SK begins_with “REC#”

Esquema final de pagos periódicos

Estos son los diseños finales del esquema. Para descargar este diseño de esquema como un archivo JSON, consulte los ejemplos de DynamoDB en GitHub.

Tabla base

Diseño de tabla base que muestra información de la cuenta y sus detalles de suscripción y recibo.

GSI-1

Esquema de GSI-1 con detalles de la suscripción, como la dirección de correo electrónico y NextPaymentDate.

GSI-2

Esquema de GSI-2 con detalles de pago, como PaymentAmount y PaymentDay.

Uso de NoSQL Workbench con este diseño de esquema

Puede importar este esquema final en NoSQL Workbench, una herramienta visual que proporciona características de modelado de datos, visualización de datos y desarrollo de consultas para DynamoDB, a fin de explorar y editar más a fondo el nuevo proyecto. Para comenzar, siga estos pasos:

  1. Descargue NoSQL Workbench. Para obtener más información, consulte Descargar NoSQL Workbench para DynamoDB.

  2. Descargue el archivo de esquema JSON que se muestra anteriormente, que ya está en el formato de modelo NoSQL Workbench.

  3. Importe el archivo de esquema JSON en NoSQL Workbench. Para obtener más información, consulte Importación de un modelo de datos existente.

  4. Una vez que haya importado en NOSQL Workbench, podrá editar el modelo de datos. Para obtener más información, consulte Edición de un modelo de datos existente.

  5. Para visualizar el modelo de datos, agregar datos de ejemplo o importar datos de ejemplo de un archivo CSV, utilice la característica Visualizador de datos de NoSQL Workbench.