Modelado de los datos del jugador de videojuegos con Amazon DynamoDB

El modelado de datos es el proceso de diseño de cómo una aplicación almacena datos en una base de datos determinada. Con una base de datos NoSQL, como DynamoDB, el modelado de datos es distinto al modelado con una base de datos relacional. Una base de datos relacional se crea por flexibilidad y puede ser una gran elección para aplicaciones analíticas. En el modelado de datos relacional, primero comienza con entidades. Cuando tiene un modelo relacional normalizado, puede satisfacer cualquier patrón de consulta que necesite en su aplicación.

Las bases de datos NoSQL (no relacionales) se diseñan por velocidad y escala, no por flexibilidad. Aunque el rendimiento de su base de datos relacional se pueda degradar a medida que aumenta, las bases de datos de escalado horizontal como DynamoDB ofrecen rendimiento uniforme a cualquier escala. Algunos usuarios de DynamoDB tienen tablas de más de 100 TB y el rendimiento de lectura y escritura de sus tablas es el mismo que cuando las tablas tenían un tamaño inferior a 1 GB.

El logro de mejores resultados con una base de datos NoSQL como DynamoDB requiere un cambio de planteamiento de la típica base de datos relacional. Utilice las siguientes prácticas recomendadas cuando modela datos con DynamoDB.

1. Enfocarse en los patrones de acceso
Cuando realice cualquier tipo de modelado de datos, comenzará con un diagrama de relación de entidades que describe los diferentes objetos (o entidades) en la aplicación y de qué manera están conectados (o las relaciones entre sus entidades).

En las bases de datos relacionales, pondrá sus entidades directamente en las tablas y especificará las relaciones con claves externas. Después de definir sus tablas de datos, una base de datos relacional ofrece un lenguaje de consulta flexible para devolver datos en la forma que necesite.

En DynamoDB, debe pensar en los patrones de acceso ante de modelar su tabla. Las bases de datos NoSQL se enfocan en velocidad y no en flexibilidad. Primero, preguntará cómo acceder a los datos y luego modelará los datos en la forma en que se accederá.

Antes de diseñar la tabla de DynamoDB, documente cada necesidad que tenga sobre los datos de lectura y escritura en la aplicación. Sea minucioso y piense sobre todos los flujos en la aplicación porque va a optimizar la tabla para los patrones de acceso.

2. Optimizar para la cantidad de solicitudes de DynamoDB
Después de documentar las necesidades del patrón de acceso de la aplicación, está listo para diseñar su tabla. Debe diseñar la tabla de manera que minimice la cantidad de solicitudes de DynamoDB para cada patrón de acceso. Idealmente, cada patrón de acceso debe requerir una única solicitud de DynamoDB, porque las solicitudes de red son lentas y esto limita la cantidad de solicitudes de red que hará en su aplicación.

Para optimizar la cantidad de solicitudes a DynamoDB, debe comprender algunos conceptos principales:

• Claves principales
• Índices secundarios
• Transacciones

3. No falsifique un modelo relacional
Las personas nuevas en DynamoDB a menudo tratan de implementar un modelo relacional por encima de DynamoDB no relacional. Si trata de hacer eso, perderá muchos de los beneficios de DynamoDB.

Los antipatrones más comunes (respuestas ineficaces a problemas recurrentes) que las personas prueban con DynamoDB son:

•  Normalización: en una base de datos relacional, normalice sus datos a fin de disminuir la redundancia de datos y el espacio de almacenaje y luego utilice uniones para combinar múltiples tablas diferentes. Sin embargo, las uniones en escala son lentas y caras. DynamoDB no permite las uniones porque reducen la velocidad a medida que la tabla crece.
• Un tipo de dato por tabla: la tabla de DynamoDB a menudo incluirá diferentes tipos de datos en una tabla única. En nuestro ejemplo, tenemos entidades de usuario, juegos y UserGameMapping en una tabla única. En una base de datos relacional, se modelaría como tres tablas diferentes.
• Demasiados índices secundarios: las personas a menudo tratan de crear un índice secundario para cada patrón de acceso adicional que necesitan. DynamoDB es sin esquemas y esto también se aplica a sus índices. Utilice la flexibilidad en sus atributos a fin de reutilizar un índice secundario único a través de tipos de datos múltiples en la tabla. Esto se llama sobrecarga de índice.

En los siguientes pasos, crearemos nuestro diagrama entidad-relación y trazaremos patrones de acceso por adelantado. Estos siempre deben ser los primeros pasos cuando utiliza DynamoDB. Luego, en los módulos siguientes, implementaremos estos patrones de acceso en el diseño de la tabla.