Simplicidad y eficiencia: desmitificando el diseño de una sola tabla en Amazon DynamoDB

¿Qué es Amazon DynamoDB?

DynamoDB, el servicio de base de datos NoSQL de AWS, se fundamenta en la idea de ofrecer una solución altamente escalable y de alto rendimiento para el almacenamiento y recuperación de datos.
Su diseño se basa en el modelo de clave-valor y proporciona una infraestructura completamente gestionada que elimina la necesidad de preocuparse por la administración de servidores. Los fundamentos de DynamoDB incluyen la capacidad de escalar horizontalmente de manera automática para manejar cargas de trabajo variables, la garantía de latencias consistentes con independencia de la escala, y la flexibilidad para almacenar y consultar datos de manera eficiente a través de índices y modelos de datos flexibles.
Este enfoque hace que DynamoDB sea ideal para aplicaciones que requieren un acceso rápido y predecible a grandes volúmenes de datos, permitiendo a los desarrolladores centrarse en la lógica de la aplicación en lugar de preocuparse por la infraestructura subyacente.

Componentes principales de DynamoDB

En DynamoDB se trabaja principalmente con tablas, elementos y atributos. Una tabla es una colección de elementos (de cero a N) y cada elemento es una colección de atributos que puede identificarse de forma exclusiva entre todos los demás elementos. Un atributo es un componente fundamental de los datos, que no es preciso dividir más, se parecen en muchos aspectos a los campos o columnas en otros sistemas de bases de datos.
DynamoDB utiliza claves principales para identificar de forma exclusiva cada uno de los elementos de la tabla e índices secundarios para proporcionar mayor flexibilidad a la hora de realizar consultas.
Una clave principal simple que consta de un solo atributo denominado clave de partición. En una tabla que solo tiene una clave de partición, no puede haber dos elementos que tengan el mismo valor de clave de partición.
El otro tipo es clave principal compuesta que consta de dos atributos, clave de partición y clave de ordenación. En una tabla que tenga una clave de partición y una clave de ordenación, es posible que varios elementos tengan el mismo valor de clave de partición. Sin embargo, esos elementos deben tener valores de clave de ordenación distintos.
Una clave principal compuesta ofrece más flexibilidad a la hora de consultar datos.
Dejando a un lado la clave principal, las tablas no tienen esquema. Esto significa que no es preciso definir de antemano los atributos ni sus tipos de datos. Cada elemento puede tener sus propios atributos diferentes.
DynamoDB admite atributos anidados hasta un máximo de 32 niveles de profundidad.
Un índice secundario le permite consultar los datos de la tabla usando una clave alternativa, además de realizar consultas basadas en la clave principal. DynamoDB no requiere que se usen índices; sin embargo, estos ofrecen a las aplicaciones mayor flexibilidad a la hora de consultar los datos.

Diseño de tabla única

Una opción para el principio básico de nuestro esquema de DynamoDB es el diseño de tabla única. El diseño de tabla única es un patrón que permite almacenar varios tipos (entidades) de datos en una sola tabla de DynamoDB.
Este enfoque lo distingue de las bases de datos SQL tradicionales, donde cada tipo único de datos reside típicamente en su propia tabla.

El objetivo es optimizar los patrones de acceso a los datos, mejorar el rendimiento y reducir los costos al eliminar la necesidad de mantener tablas múltiples y relaciones complejas entre ellas. Esto es posible porque DynamoDB almacena elementos con la misma clave de partición (lo que se conoce como recopilación de elementos) en las mismas particiones entre sí. En este diseño, los diferentes tipos de datos se almacenan como elementos en la misma tabla y cada elemento se identifica mediante una clave de clasificación única.

Ventajas

• Localización de datos para admitir consultas para varios tipos de entidades en una sola llamada a la base de datos
• Logra un rendimiento de lectura y escritura muy rápida y predecible
• Reduce los costos financieros y de latencia generales de las lecturas
• Reduce el número de tablas que hay que administrar
• Suaviza el tráfico hacia la tabla

Desventajas

• La curva de aprendizaje puede ser pronunciada debido a un diseño paradójico en comparación con las bases de datos relacionales, debemos aprender a des-normarlizar las relaciones entre las entidades
• Los requisitos de datos deben ser coherentes en todos los tipos de entidades
• Todos los datos modificados se propagarán a DynamoDB Streams aunque solo es necesario procesar un subconjunto de entidades
• Al usar GraphQL, el diseño de una sola tabla será más difícil de implementar
• Cuando se utilizan clientes de SDK de nivel superior, como DynamoDBMapper de Java o Cliente mejorado, puede resultar más difícil procesar los resultados porque los elementos de la misma respuesta pueden est ar asociados a clases diferentes

¿Cuándo implementar?

El factor clave para contemplar, es si su aplicación exhibe patrones de acceso relativamente predecibles. Tenemos que determinar cómo vamos a trabajar y usar nuestros datos para satisfacer las necesidades empresariales.

Podemos cambiar la pregunta y contestar: ¿cuándo no implementar el diseño en una sola tabla?

1. Cuando no conocemos los patrones de acceso a los datos, esto incluye cuando estamos desarrollando al mismo tiempo de análisis, no hay tiempo de alinear el diseño. Todo es rápido.
2. Cuando usamos GraphQL, por ejemplo, por medio de AppSync, esto porque es necesario tener un esquema determinado por cada data source.

Pasos para implementar

1. Diagrama entidad relación, debemos entender las entidades que tenemos en nuestra aplicación y sus relaciones.
2. Encontrar nuestros patrones de acceso.
3. Modelar la llave primaria, nuestro partition key y sort key.
4. Crear los índices secundarios necesarios para las consultas que vamos a tener, solventar nuestros patrones de acceso.

Mitos en el diseño de una sola tabla con DynamoDB

Laberinto de la complejidad

Similar al mito del Minotauro en el laberinto, se asume que el diseño de una sola tabla es inherentemente complejo y difícil de navegar.
Contrario a la creencia, el diseño puede simplificarse mediante estrategias inteligentes, eliminando capas innecesarias y facilitando la comprensión y gestión de los datos.

Consultas inalcanzables

Similar a Sísifo y su tarea interminable, se piensa que ciertas consultas son inalcanzables en una sola tabla.
Con un modelado de datos astuto y el uso eficiente de índices, muchas consultas específicas pueden abordarse de manera eficaz, desafiando la noción de inaccesibilidad.

Peso insoportable del rendimiento

Reflejando la tarea impuesta a Hércules de llevar las vestiduras de Ónfale como castigo, se piensa que el rendimiento en una sola tabla será una carga insoportable.
Contrario a la creencia de una carga pesada, el diseño de una sola tabla puede aliviar la complejidad, permitiendo una gestión más eficiente del rendimiento al consolidar datos y simplificar el acceso a la información. Al optimizar la distribución de datos y utilizar estrategias de escalabilidad automática, el rendimiento puede mantenerse robusto incluso en condiciones de tráfico intenso.

Fuego de la escalabilidad

Como Prometeo trajo el fuego a los humanos, se supone que la escalabilidad en una sola tabla es un regalo inalcanzable.
DynamoDB ofrece escalabilidad horizontal automática, permitiendo gestionar grandes volúmenes de datos y adaptarse dinámicamente a las demandas de la aplicación.