Normalmente cuando comenzamos a diseñar un esquema de datos, consideramos una base de datos relacional como primera opción. Digamos que se tiene por ejemplo una aplicación que registra eventos de auditoria de las acciones que realizan los usuarios. Al iniciar la aplicación la base de datos es manejable, pero con el tiempo comenzará a crecer a razón de cientos de gigas por semana. El procesamiento y lectura de estos eventos de auditoria comienzan a representa un 25% del consumo de recursos de nuestro servidor en cuando a IOPS y CPIU. Adicionalmente, otros procesos que utilizan el servidor generan documento XML, JSON y binarios en otras tablas de la base de datos, junto con nuestros eventos de auditoria. El historial de varios meses continua creciendo y todo esto en una infraestructura tradicional en donde debemos cubrir licencias, planificar y comprar recursos para aumentar la capacidad de almacenamiento y escalamiento de nuestro servidor. Todo es se convierte un desafío importante cuya complejidad varía de acuerdo con la tecnología y recursos financieros que tengamos para aprovisionarnos. ¿Qué podemos hacer para que que esto sea más sencillo? Migrar nuestra base de datos a la nube.

Existen diferentes estrategias para reducir los costos de bases de datos, al mismo tiempo que mejoramos la disponibilidad y simplificamos la administración de la base de datos. Antes que nada debemos conocer los diferentes tipos de almacenes de datos que hay disponibles en AWS.

Sabemos que los RDBMS (Gestión de bases de datos relacionales) son utilizados por la mayoría de las aplicaciones que generan procesamiento de transacciones. Entre los motores de bases de datos más populares de este estilo, tenemos MySql, SQL Server y Oracle. Este tipo de motores de base datos puede:

• Generar problemas de desempeño. A menos que tengamos los recursos para ir aumentando la capacidad de procesamiento y disco de nuestros servidores de forma constante, las tablas más grande siempre necesitaran más tiempo para ser consultadas y la combinación de transacciones de tipo lectura/escritura de este tipo de tablas, puede generar problemas de lentitud.
• Aumento del costo total de propiedad (CTO). Para mejorar algunas consultas lentas y mejorar el trafico lectura/escritura en nuestra base de datos, debemos escalar verticalmente agregando más capacidad de computo y almacenamiento. Si necesitáramos aumentar la capacidad solamente por una temporada del año, tendríamos que hacer la inversión necesaria pero no podremos reducir la escala, lo cual aumenta el CTO.

Existen otros esquemas de base de datos, así en lugar de utilizar solo almacenamiento de tipo transaccional, al migrar nuestra base de datos a AWS podríamos utilizar otros almacenes de datos que se adapten a nuestro caso de uso. AWS nos permite asignar la escala de recursos que necesitamos de acuerdo con nuestro crecimiento y podemos aumentar y disminuir recursos bajo demanda. La siguiente tabla muestra algunos de diferentes almacenes de datos que existen en AWS que pueden complementar una base de datos relacional:

Al incorporar algunos de estos almacenes de datos en nuestra arquitectura para el procesamiento de datos, lograremos mejorar el desempeño y disponiblidad de nuestra aplicación y reducir costos. Utilizando DynamoDB, Amazon S3 o Amazon RDS podremos minimizar el TCO de bases de datos transaccionales de gran volumen que tengamos en nuestra propia instalación. El siguiente diagrama muestra la reingeniería de una gran base de datos relacional en varios almacenes de datos en AWS:

Por supuesto que este enfoque es muy diferente al de migrar una base de datos relacional directamente hacia un Amazon RDS o Amazon EC2, debido a 2 razones:

1. El enfoque que queremos aplicar esta enfocado en una reingenieria, donde debemos identificar que parte de la base de datos podemos migrar a Amazon S3 y Amazon DynamoDB. Este enfoque también se conoce como aplicaciones nativas en la nube donde aprovechamos los diferentes servicios de Amazon de acuerdo a las necesidades de nuestra aplicación. Solo que este caso es convertir una aplicación tradicional a la nube.
2. Si las aplicaciones que utilizan la base de datos utilizan características especiales de ese motor, la reingenieria sera más complicada y se tendría que evaluar el costo beneficio de la misma.. En este caso una migración uno a uno sería mas simple y podría realizarse de manera sencilla utilizando el Servicio de Migración de Bases de Datos de AWS (DMS). Mientras más partes de la base de datos logremos separar mayor sera el ahorro en costos que logremos.

La reingenieria de la de la base de datos, la separaremos en 3 partes:

1. Subconjunto de datos hacia Amazon RDS o Amazon EC2
2. Objetos grandes hacia Amazon S3
3. Subconjunto de datos hacia un almacén NoSql como DynamoDB

Subconjunto de datos hacia Amazon RDS o Amazon EC2

Esta es la parte más sencilla, consiste en validar que partes de nuestra base de datos no queremos que sufra cambios y se mantenga igual. Esta migración la podemos realizar al mismo motor de base datos si utilizamos uno compatible con Amazon RDS o realizar nuestra propia instalación en instancias EC2 a donde realicemos la migración.

Amazon RDS es un servicio administrado que facilita la configuración, el funcionamiento y el crecimiento de una base de datos relacional en la nube. Amazon RDS hace automáticamente el trabajo que involucra la creación de una base de datos relacional, desde el abastecimiento de la capacidad de la infraestructura hasta la instalación del software de la base de datos. Amazon RDS también se encarga de las tareas administrativas comunes, como realizar copias de seguridad y arreglar el software que empodera su base de datos con implementaciones múltiples de Zonas de Disponibilidad, Amazon RDS gestiona la sincronización de réplica de datos en las Zonas de Disponibilidad con conmutación por error automática. Al migrar su base de datos a Amazon RDS, puede ahorrar en el TCO, reducir la sobrecarga operativa y lograr mayores niveles de disponibilidad y confiabilidad para su base de datos relacional.

Las siguientes preguntas nos ayudaran a determinar que que partes de nuestra base de datos podemos dejar sin cambios:

• ¿Está la mayoría de los datos en el conjunto de datos, son datos transaccionales que se leen y escriben frecuentemente como filas individuales o grandes números o pequeños lotes?
• ¿El procesamiento y almacenamiento de estos datos utilizan características específicas de la base de datos, como las opciones de base de datos?
• ¿Existe mucho código asociado para este conjunto de datos que es difícil de cambiar? Por ejemplo, millones o líneas de código PL/SQL en la base de datos Oracle.
• ¿El código de la aplicación y la interfaz de usuario para este conjunto de datos que es difícil de cambiar?
• ¿Nuestra aplicación genera consultas SQL complejas en contra de estos datos y se une a datos de múltiples tablas?
• ¿Las definiciones de tabla y entidad (el número de columnas, tipos de datos y similares) en su esquema de base de datos se mantendrán fijas a medida que evolucione su aplicación? ¿Le gustaría imponer restricciones a través de diferentes tablas en su modelo de datos mientras almacena los datos?

Si respondemos “Sí” a todas o a la mayoría de estas preguntas sobre un conjunto de datos, ese conjunto es adecuado para migrar a la base de datos relacional en Amazon RDS o Amazon EC2. Para migrar estos datos podemos utilizar herramientas nativas de nuestro motor de base de datos, pero también podríamos utilizar AWS DMS, AWS Herramienta de conversión de Esquemas o cualquier otra herramienta creada por terceros que consideremos adecuada para esta tarea. En particular AWS DMS, soporta migración de bases de datos homogeneas y heterogéneas, permite también realizar una migración completa o progresiva para ayudar a reducir el tiempo de inactividad de la aplicación.

Objetos grandes hacia Amazon S3

Debido a que muchos motores de bases de datos transaccionales lo permiten, algunas aplicaciones son diseñadas para almacenar campos tipo BLOB (Binary Large Objects) o campos que almancenan muchos caracteres como por ejemplo documentos XML o JSON.  Utilizar este tipo de datos directamente en las tablas de de bases de datos relacionales ofrece algunos beneficios como consistencia en un punto de tiempo determinado (al momento de restaurar respaldos), facilidad de acceso y controles de seguridad.

Pero si nuestra aplicación esta generando este tipo de grandes objetos en gigabytes por segundo, el consumo e impacto en el rendimiento de red, disco, memoria y CPU será muy grande.  Utilizar Amazon S3 como mecanismo para almacener y recuperar objetos grandes puede mejorar el desempeño y disponibilidad de nuestra aplicación, si la latencia adicional de utilizar este servicio adicional es aceptable para nuestra plataforma.  Amazon S3 brinda acceso a una infraestructura de almacenamiento de datos altamente escalable, confiable, rápida y económica. Debido a que Amazon S3 es altamente escalable, podemos comenzar poco a poco y hacer crecer nuestra aplicación como deseemos, sin comprometer el rendimiento ni la confiabilidad.

Este cambio significa un cambio en nuestra aplicación para almacenar la ruta del objeto y en caso de que deseemos utilizar versionamientos, asignar también el ID de versión del objeto en Amazon S3.  Este cambio es mínimo si al compararlo con los beneficios de ahorro que obtendremos de TCO y mejoras en el rendimiento de la aplicación en general.

Otra conjunto de datos que puede trasladarse a Amazon S3, es el historial de transacciones. Muchas veces, este historial se mantiene en bases de datos o tablas dentro del mismo servidor, aumentando constantemente el almacenamiento que se necesita.  Este historial tampoco es accedido con tanta frecuencia, lo que genera una perdida de recursos. Este historial puede ser almacenado y organizado en carpetas en Amazon S3 y ser analizado solo cuando sea necesario.  Inclusive se pueden generar el historial de tal forma que sea consultado también como una base de datos utilizando Amazon Athena.

Subconjunto de datos hacia un almacén NoSql como DynamoDB

La ultima parte de esta estrategia comprende utilizar un almacén de datos NoSql como DynamoDB para parte de un subconjunto de su base de datos relacional actual. Amazon DynamoDB es una base de datos NoSQL totalmente gestionada que admite estructuras de datos clave y de valores y documentos. DynamoDB evita las cargas administrativas de operar y escalar una base de datos distribuida para que no tengamos que preocuparnos por el aprovisionamiento de hardware, instalación y configuración, replicación, parches de software o escalado de clústeres del hardware.

Las preguntas que nos ayudaran a identificar los datos que se pueden almacenar en un almacén de datos NoSQL como DynamoDB, son:

• ¿Los datos se escriben con frecuencia o a alta velocidad?
• ¿Los registros individuales tienen números variables de campos y atributos que no se pueden determinar como parte de su diseño de esquema?
• ¿Los datos se escriben independientemente de otras tablas en el esquema?
• ¿Se pueden leer los datos como eventualmente consistentes? La consistencia eventual es cuando los datos escritos en la base de datos pueden no estar disponibles inmediatamente para las lecturas, y estarán disponibles finalmente para las lecturas en segundos.
• ¿Las tablas de bases de datos relacionales almacenan documentos y aplicaciones JSON que puede consultar con consultas simples?

Si respondemos “Sí” a todas o la mayoría de estas preguntas, entonces ese subconjunto de datos es adecuado para migrar a un almacén de datos NoSQL como Amazon DynamoDB.

Los datos de la base relacional no se deben mover a un repositorio NoSQL cuando:

• Se utilizan consultas relacionadas con muchas tablas a nivel la interfaz de usuario de su aplicación.
• Se usa mucho como fuente de procesamiento analítico en línea (OLAP).
• Se trata como tipos de datos BLOB.
• Tiene tamaños de registro individuales mayores a 400 KB.
• La aplicación necesita cantidades significativas de cambios.

Después de elegir que conjunto de datos se puede mover a DynamoDB, el diseño del modelo de datos es clave para que el rendimiento y crecimiento a futuro sea eficiente. DynamoDB utiliza múltiples particiones para distribuir los datos en diferente servidores físicos, estas particiones se realizan en base al valor de una firma digital (hash) de la la clave principal de una tabla de DynamoDB. Dependiendo de cual sea el patrón de lectura/escritura de datos de nuestra aplicación debemos seleccionar cual es la clave de partición.

Con Amazon DynamoDB solo pagaremos por la capacidad de lectura/escritura que necesitemos habilitar, y en caso de que estos valores puedan tener cambios inesperados podemos utilizar el modelo de costos bajo demanda, que permite atender miles de transacciones por segundo de forma automática.

Resumen

Hemos analizado una estrategia sobre cómo dividir  bases de datos monolíticas en diferentes almacenes de datos especialmente diseñados a medida que migra sus bases de datos a AWS. Podemos obtener importantes ahorros en costos de licenciamiento e infraestructura, así como una mejor disponibilidad al identificar el almacén de datos adecuado para nuestros datos.