Principios básicos del modelado de datos en DynamoDB
En esta sección se trata la capa fundamental mediante el examen de los dos tipos de diseño de tablas: tabla única y tabla múltiple.
Principios básicos de 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. 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
-
Reduce los costos financieros y de latencia generales de las lecturas:
-
Una sola consulta para dos elementos con un total de menos de 4 KB es 0,5 RCU de coherencia eventual
-
Dos consultas para dos elementos con un total de menos de 4 KB es 1 RCU de coherencia eventual (0,5 cada RCU)
-
El tiempo para devolver dos llamadas independientes a la base de datos será, de media, superior al de una sola llamada
-
-
Reduce el número de tablas que hay que administrar:
-
No es necesario mantener los permisos en varios roles o políticas de IAM
-
La administración de la capacidad de la tabla se calcula de media en todas las entidades, lo que suele dar como resultado un patrón de consumo más predecible
-
El monitoreo requiere menos alarmas
-
Las claves de cifrado administradas por el cliente solo se deben rotar en una tabla
-
-
Suaviza el tráfico hacia la tabla:
-
Al agregar varios patrones de uso a la misma tabla, el uso general tiende a ser más fluido (de la misma manera que el rendimiento de un índice bursátil tiende a ser más fluido que el de cualquier acción individual), lo que funciona mejor para lograr una mayor utilización con tablas de modos aprovisionadas
-
Desventajas
-
La curva de aprendizaje puede ser pronunciada debido a un diseño paradójico en comparación con las bases de datos relacionales
-
Los requisitos de datos deben ser coherentes en todos los tipos de entidades
-
Las copias de seguridad son todo o nada, por lo que si algunos datos no son de vital importancia, considere guardarlos en una tabla distinta
-
El cifrado de tablas se comparte entre todos los elementos. Para las aplicaciones de varios inquilinos con requisitos de cifrado de inquilinos individuales, se requeriría el cifrado del cliente
-
Las tablas con una combinación de datos históricos y datos operativos no obtendrán tantos beneficios al habilitar la clase de almacenamiento de acceso poco frecuente. Para obtener más información, consulte Clases de tablas de DynamoDB
-
-
Todos los datos modificados se propagarán a DynamoDB Streams aunque solo se tenga que procesar un subconjunto de entidades.
-
Gracias a los filtros de eventos de Lambda, esto no afectará a la factura cuando utilice Lambda, pero supondrá un costo adicional si utiliza la Kinesis Consumer Library
-
-
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 estar asociados a clases diferentes
Cuándo se debe usar
El diseño de tabla única es el patrón de diseño recomendado para DynamoDB, a menos que el caso de uso se vea afectado en gran medida por alguna de las desventajas anteriores. Para la mayoría de los clientes, los beneficios a largo plazo superan los desafíos a corto plazo de diseñar las tablas de esta manera.
Principios básicos de diseño de tabla múltiple
La segunda opción para el principio básico de nuestro esquema de DynamoDB es el diseño de tabla múltiple. El diseño de tabla múltiple es un patrón que se parece más a un diseño de base de datos tradicional, en el que se almacena un único tipo (entidad) de datos en cada tabla de DynamoDB. Los datos de cada tabla seguirán organizados por clave de partición, por lo que el rendimiento dentro de un solo tipo de entidad se optimizará en función de la escalabilidad y el rendimiento, pero las consultas en varias tablas se deben realizar de forma independiente.
Ventajas
-
Más fácil de diseñar para aquellos que no están acostumbrados a trabajar con un diseño de tabla única
-
Implementación más sencilla de los solucionadores de GraphQL debido a que cada resolución se asigna a una sola entidad (tabla)
-
Permite requisitos de datos únicos en diferentes tipos de entidades:
-
Se pueden realizar copias de seguridad de las tablas individuales que son críticas
-
El cifrado de tablas se puede administrar para cada tabla. Para las aplicaciones de múltiples inquilinos con requisitos de cifrado de inquilinos individuales, las tablas de inquilinos independientes permiten que cada cliente tenga su propia clave de cifrado
-
La clase de almacenamiento de acceso poco frecuente se puede habilitar solo en las tablas con datos históricos para obtener todos los beneficios de ahorro de costos. Para obtener más información, consulte Clases de tablas de DynamoDB
-
-
Cada tabla tendrá su propio flujo de datos de cambios, lo que permitirá diseñar una función de Lambda dedicada para cada tipo de elemento, en lugar de un único procesador monolítico
Desventajas
-
Para los patrones de acceso que requieren datos en varias tablas, se requerirán varias lecturas de DynamoDB y es posible que sea necesario procesar o unir los datos en el código del cliente.
-
Las operaciones y el monitoreo de varias tablas requieren más alarmas de CloudWatch y cada tabla se debe escalar de forma independiente
-
Los permisos de cada tabla se deberán administrar de forma independiente. La adición de tablas en el futuro requerirá un cambio en los roles de IAM o políticas necesarios
Cuándo se debe usar
Si los patrones de acceso de su aplicación no tienen la necesidad de consultar varias entidades o tablas a la vez, entonces el diseño de tablas múltiples es un enfoque bueno y suficiente.
