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.

Tiempo para completar el módulo: 20 minutos


  • Paso 1: crear el diagrama entidad-relación

    El primer paso de cualquier ejercicio de modelado de datos es crear un diagrama que muestre las entidades en la aplicación y cómo se relacionan unas con otras.

    En la aplicación, tenemos las siguientes entidades:
    • Usuario
    • Juego
    • UserGameMapping

    Una entidad de Usuario representa un usuario en nuestra aplicación. Un usuario puede crear múltiples entidades de Juego y el creador del juego determinará que mapa se juega y cuando comenzará el juego. Un Usuario puede crear múltiples entidades de Juego, así que hay una relación de uno a muchos entre Usuarios y Juegos.

    Finalmente, un Juego contiene múltiples Usuarios y un Usuario puede jugar múltiples y diferentes Juegos con el paso del tiempo. Por lo tanto, existe una relación de muchos a muchos entre los Usuarios y los Juegos. Podemos representar esta relación con la entidad UserGameMapping.

    Con estas entidades y relaciones en mente, a continuación se muestra el diagrama entidad-relación.

    Module2-step1

    (Haga clic para ampliar)

    Module2-step1
  • Paso 2: considerar los patrones de acceso al perfil de usuario

     Los usuarios de nuestro juego necesitan crear perfiles de usuario. Estos perfiles incluyen datos como nombre de usuario, avatar, estadísticas del juego y otra información sobre cada usuario. El juego exhibe estos perfiles de usuario cuando el usuario inicia sesión. Otros usuarios pueden ver el perfil de un usuario para revisar las estadísticas de su juego y otros detalles.

    Mientras el usuario juega, las estadísticas del juego se actualizan para reflejar la cantidad de juegos que el usuario ha jugado, los que ha ganado y la cantidad de muertes por parte del usuario.

    En función de esta información, tenemos tres patrones de acceso:

    •  Crear el perfil de usuario (Escribir)
    •  Actualizar el perfil de usuario (Escribir)
    • Obtener el perfil de usuario (Leer)
  • Paso 3: considerar los patrones de acceso previos al juego

    Este es un juego de battle royale. Los jugadores pueden crear un juego en un mapa particular y otros jugadores se pueden unir al juego. Cuando 50 jugadores se unen al juego, el juego comienza y no pueden unirse jugadores adicionales.

    Cuando los jugadores buscan juegos para unirse, pueden querer jugar un mapa en particular. A otros jugadores no les importa el mapa y quieren explorar juegos abiertos en todos los mapas.

    En función de esta información, tenemos los siguientes siete patrones de acceso:

    • Crear juego (Escribir)
    • Buscar juegos abiertos (Leer)
    • Buscar juegos abiertos por mapa (Leer)
    • Ver juego (Leer)
    • Ver usuarios en el juego (Leer)
    • Unirse al juego para un usuario (Escribir)
    • Comenzar juego (Escribir)
  • Paso 4: patrones de acceso en el juego y después del juego

    Finalmente, consideremos los patrones de acceso durante y después de un juego.

    Durante el juego, los jugadores tratan de vencer a otros jugadores con el objetivo de ser el último jugador en pie. Nuestra aplicación rastrea cuántas muertes tiene cada jugador durante un juego, así como también cuanto tiempo sobrevive en el juego. Si un jugador es uno de los últimos tres sobrevivientes en un juego, recibe una medalla de oro, plata o bronce por el juego.

    Posteriormente, los jugadores pueden querer revisar los juegos que ellos u otros han jugado.

    En función de esta información, tenemos tres patrones de acceso:

    • Actualizar el juego para el usuario (Escribir)
    • Actualizar el juego (Escribir)
    • Encontrar todos los juegos anteriores para el usuario (Leer)

    Ahora hemos mapeado todos los patrones de acceso para el juego. En los módulos siguientes, implementaremos estos patrones de acceso con DynamoDB.

    Tenga en cuenta que la fase de planificación puede llevar algunas iteraciones. Comience con una idea general de los patrones de acceso que la aplicación necesita. Mapee la clave principal, los índices secundarios y los atributos en la tabla. Regrese al principio y asegúrese de que todos los patrones de acceso sean satisfactorios. Cuando esté seguro de que la fase de planificación está completa, avance con la implementación.