Amazon DynamoDB: Cuándo usarlo?

En este artículo, explicaremos cómo evaluar DynamoDB como un posible servicio de base de datos para nuestra aplicación. Empecemos diciendo que AWS cree en 'database freedom'. Nos alienta a evaluar y elegir la base de datos adecuada para el tipo de datos, modelo de acceso y escalabilidad que necesitamos. También cree que nuestros desarrolladores y administradores de sistemas deberían tener la libertad de crear y operar nuestas aplicaciones mientras dejan la administración de operaciones a AWS. Esto es particularmente importante para las operaciones de bases de datos a gran escala.

Las cloud-native applications a menudo son arquitectónicamente diferentes de las aplicaciones legacy, y se implementan regularmente con bajo acoplamiento y múltiples niveles autoescalado en cómputo. Es importante que nos tomemos el tiempo para considerar nuestras opciones y probarlas según sea necesario. Desarrollemos una creencia en la persistencia políglota: elijamos la tecnología de base de datos adecuada para sus aplicaciones nativas y legacy de la nube. Debemos resistir la tentación de usar el mismo enfoque de base de datos para cada desafío de desarrollo de aplicaciones.

Entonces, podemos usar DynamoDB si:

• Hemos tenido problemas de escalabilidad con otros sistemas de bases de datos tradicionales.
• Participamos activamente en el desarrollo de una aplicación o servicio. No siempre tiene sentido migrar aplicaciones legacy que no están en desarrollo, a menos que estemos dispuestos a invertir tiempo y esfuerzo para volver a implementar la capa de acceso a datos, el código SQL o los procedimientos y funciones almacenados de esa aplicación.
• Estamos trabajando con una carga de trabajo OLTP. Las lecturas y escrituras de alto rendimiento son fáciles de administrar con DynamoDB, y podemos esperar un rendimiento que sea efectivamente constante en cargas muy variables.
• Estamos implementando una aplicación de misión crítica que debe estar altamente disponible en todo momento sin intervención manual.
• No tenemos suficiente personal con respecto a la gestión de la capacidad de base de datos adicional y necesitamos reducir la carga de trabajo de su equipo de operaciones.
• Requerimos un alto nivel de durabilidad de los datos, independientemente de su estrategia de copia de seguridad y restauración.
• Tener datos insuficientes para pronosticar picos y valles en el rendimiento requerido de la base de datos.

Antes de decidir usar DynamoDB, deberíamos poder responder "SI" a la mayoría de las siguientes preguntas de evaluación:

1. ¿Podemos organizar nuestros datos en jerarquías o una estructura agregada en una o dos tablas?
2. ¿Es importante la protección de datos?
3. ¿Las copias de seguridad tradicionales no son prácticas o tienen un costo prohibitivo debido a la tasa de actualización de la tabla o al tamaño general de los datos?
4. ¿La carga de trabajo de nuestra base de datos varía significativamente según la hora del día o está impulsada por una alta tasa de crecimiento o eventos de alto tráfico?
5. ¿Nuestra aplicación o servicio requiere constantemente tiempo de respuesta en mili-segundos individuales, independientemente de la carga y sin esfuerzo de ajuste?
6. ¿Necesitamos proporcionar servicios en una configuración escalable, replicada o global?
7. ¿Nuestra aplicación necesita almacenar datos en el rango de tamaño de high-terabytes?
8. ¿Estamos dispuestos a invertir en una curva de aprendizaje NoSQL corta pero posiblemente empinada para nuestros desarrolladores?

Dicho eso, ahora mencionamos algunos ejemplos para comprender cuándo usar y cuándo no usar DynamoDB.

Workloads adecuadas para DynamoDB:

DynamoDB es una base de datos NoSQL, lo que significa que funcionará mejor para cargas de trabajo que involucran datos no relacionales. Algunos de los casos de uso más comunes para cargas de trabajo no relacionales son:

• Ad-Tech: Capturing browser cookie state.
• Mobile applications: Storing application data and session state.
• Gaming applications: Storing user preferences and application state, Storing players’ game state.
• Consumer “voting” applications: Reality TV contests, Superbowl commercials.
• Large Scale Websites: Session state, User data used for personalization, Access control.
• Application monitoring: Storing application log and event data, JSON data.
• Internet of Things: Sensor data and log ingestion

Todos estos casos de uso se benefician de una combinación de las características que hacen que las bases de datos NoSQL sean tan poderosas. Las aplicaciones de Ad-Tech generalmente requieren una latencia extremadamente baja, lo que es muy adecuado para el rendimiento de lectura y escritura de un solo dígito de milisegundos de DynamoDB. Las aplicaciones móviles y las aplicaciones de votación del consumidor a menudo tienen millones de usuarios y necesitan manejar miles de solicitudes por segundo. DynamoDB puede escalar horizontalmente para cumplir con esta carga. Finalmente, las soluciones de monitoreo de aplicaciones generalmente ingieren cientos de miles de puntos de datos por minuto, y el modelo de datos schema-less de DynamoDB, el alto rendimiento de E/S y el soporte para un tipo de datos JSON nativo es una gran opción para este tipo de aplicaciones.

Otra característica importante a tener en cuenta al determinar si una carga de trabajo es adecuada para una base de datos NoSQL como DynamoDB es si requiere escala horizontal. Una aplicación móvil puede tener millones de usuarios, pero cada instalación de la aplicación solo leerá y escribirá datos de sesión para un solo usuario. Esto significa que los datos de la sesión del usuario en la tabla DynamoDB se pueden distribuir en múltiples particiones de almacenamiento. Una lectura o escritura de datos para un usuario dado se limitará a una sola partición. Esto permite que la tabla DynamoDB se escale horizontalmente: a medida que se agregan más usuarios, se crean más particiones. Mientras las solicitudes para leer y escribir estos datos se distribuyan uniformemente entre las particiones, DynamoDB podrá manejar una gran cantidad de acceso a datos concurrentes. Este tipo de escala horizontal es difícil de lograr con un RDBMS sin el uso de "sharding", que puede agregar una complejidad significativa a la capa de acceso a datos de una aplicación. Cuando los datos en un RDBMS están "sharded", se dividen en diferentes instancias de bases de datos. Esto requiere mantener un índice de las instancias y el rango de datos que contienen. Para leer y escribir datos, una aplicación cliente necesita saber qué fragmento contiene el rango de datos que se leerán o escribirán. "Sharding" también agrega gastos generales administrativos y costos: en lugar de una sola instancia de base de datos, ahora es responsable de mantener varios en funcionamiento.

También es importante evaluar el requerimiento de consistencia de datos de una aplicación al determinar si una carga de trabajo es adecuada para DynamoDB. En realidad, hay dos modelos de consistencia compatibles con DynamoDB: strong and eventual consistency, y la primera requiere más IO aprovisionada que la segunda. Esta flexibilidad permite al desarrollador obtener el mejor rendimiento posible de la base de datos al tiempo que puede soportar los requerimientos de consistencia de la aplicación. Si una aplicación no requiere lecturas "strongly consistent", lo que significa que las actualizaciones realizadas por un cliente no necesitan ser visibles de inmediato para otros, entonces el uso de un RDBMS que forzará una fuerte consistencia puede resultar en un 'impuesto' sobre el rendimiento sin beneficio neto a la aplicación. La razón es que una fuerte consistencia generalmente implica tener que bloquear una parte de los datos, lo que puede causar cuellos de botella en el rendimiento.

Workloads inadecuadas para DynamoDB:

No todas las cargas de trabajo son adecuadas para una base de datos NoSQL como DynamoDB. Si bien en teoría se podría implementar un modelo clásico de entidad-relación utilizando tablas y elementos de DynamoDB, en la práctica, sería extremadamente engorroso trabajar con él. Los sistemas transaccionales que requieren relaciones bien definidas entre entidades todavía se implementan mejor utilizando un RDBMS tradicional. Algunas otras cargas de trabajo inadecuadas incluyen:

• Ad-hoc queries
• OLAP
• BLOB storage

Debido a que DynamoDB no admite un lenguaje de consulta estándar como SQL, y porque no existe el concepto de una unión de tabla, la construcción de Ad-hoc queries no es tan eficiente como lo es con RDBMS. Es posible ejecutar dichas consultas con DynamoDB, pero requiere el uso de Amazon EMR y Hive. Del mismo modo, las aplicaciones OLAP también son difíciles de entregar, porque el modelo de datos dimensionales utilizado para el procesamiento analítico requiere unir tablas de hechos a tablas de dimensiones. Finalmente, debido a la limitación de tamaño de un elemento DynamoDB, el almacenamiento de BLOB a menudo no es práctico. DynamoDB admite un tipo de datos binarios, pero esto no es adecuado para almacenar objetos binarios grandes, como imágenes o documentos. Sin embargo, almacenar un puntero en la tabla DynamoDB en un BLOB grande almacenado en Amazon S3 soporta fácilmente este último caso de uso.

Fuente: AWS Documentation