Reduzca el costo de la base de datos y mejore la disponibilidad cuando migre a la nube de AWS

Digamos que tiene una aplicación que utiliza tablas de base de datos para almacenar datos de registro y de flujo de clics. Puede almacenar sus datos en una base de datos relacional para facilitar las tareas de desarrollo y administración. Cuando inicia su aplicación, la base de datos es manejable al principio, pero crece a cientos de gigabytes por semana. Tan solo el almacenamiento y la recuperación de datos consumen el 20 por ciento de IOPS y CPU en su instancia de base de datos relacional. Además, las aplicaciones almacenan documentos XML, JSON y binarios en las tablas de bases de datos junto con datos transaccionales. Los datos históricos siguen creciendo cada mes. Sus costos tradicionales de infraestructura y licencias de la base de datos local están aumentando, y escalar la base de datos se ha convertido en un gran desafío. ¿Qué puede hacer?

En esta publicación del blog, explicamos las estrategias para reducir los costos de su base de datos y mejorar la disponibilidad a medida que migra a la nube de AWS.

Tipos de almacenes de datos

Los sistemas de gestión de bases de datos relacionales (RDBMS) son el núcleo de la mayoría de los sistemas de procesamiento de transacciones. El almacenamiento de todos los datos en un RDBMS puede:

• Causar problemas de desempeño. Las tablas más grandes necesitan más tiempo para consultar los datos. El alto tráfico de lectura/escritura en un grupo específico de tablas hace lenta otras consultas en una base de datos.
• Aumenta su costo total de propiedad (TCO). Para proveer más tráfico de lectura/escritura, debe escalar la base de datos verticalmente agregando más capacidad de almacenamiento y cómputo. Aunque esto podría ser para incrementar el tráfico estacional, debe realizar grandes inversiones iniciales para atender el tráfico de su aplicación. Además, no puede reducir la escala del servidor de la base de datos, lo cual aumenta su TCO.

En lugar de utilizar solo el almacenamiento de bases de datos relacionales, su aplicación puede almacenar sus datos en almacenes de datos especialmente diseñados al migrar a AWS. El almacén de datos que utiliza su aplicación depende de su patrón de acceso. También depende de la escala la cual anticipa el crecimiento de sus datos y de la facilidad que necesite para acceder a los datos. Estos tipos de almacén de datos, sus propósitos y ejemplos de cada tipo se muestran en la siguiente tabla.

Utilice estos almacenes de datos en su arquitectura de procesamiento de datos para mejorar el desempeño y la disponibilidad de su aplicación y reducir los costos. En esta publicación, explicamos cómo minimizar el TCO de las bases de datos tradicionales de gran volumen en las instalaciones, utilizando los siguientes servicios de AWS:

• DynamoDB
• Amazon S3
• Servicio de base de datos relacional de Amazon  (Amazon RDS)

El siguiente diagrama muestra la refactorización de una gran base de datos relacional en múltiples almacenes de datos como DynamoDB y Amazon S3.

Por dos razones, este enfoque es diferente que migrar una base de datos a un motor de base de datos (como Oracle a PostgreSQL) en Amazon RDS o Amazon EC2.

Primero, muchas personas construyen aplicaciones que usan motores de bases de datos comerciales. Estas aplicaciones pueden usar una característica que es específica de un motor de base de datos relacional. Es posible que el motor no esté disponible en los motores de base de datos de código abierto y que requiera una cantidad significativa de trabajo adicional. Mantener el mismo motor de base de datos relacional con una huella más pequeña en la arquitectura de estado final le ayuda a moverse a la nube más rápido. De esta manera, también minimiza la cantidad de cambio requerido en la aplicación o la capa de base de datos. La migración de bases de datos de igual a igual siempre es la más fácil porque los objetos de código y de base de datos se migran utilizando herramientas de migración de base de datos nativas o el Servicio de Migración de Base de Datos de AWS (DMS).

Segundo, en este enfoque, le sugerimos que identifique una parte de la base de datos que se puede migrar a Amazon S3 y Amazon DynamoDB. Puede ver esto en el diagrama anterior. Esto le ayuda a abordar los problemas de desempeño y TCO causados por el rápido crecimiento de los datos en los registros, los datos del flujo de clics, los grandes objetos y similares.

En el resto de esta publicación, discutimos el enfoque en tres partes:

1. Mover un subconjunto de la base de datos relacional a Amazon EC2 o Amazon RDS.
2. Mover objetos grandes de la base de datos relacional a Amazon S3.
3. Mover un subconjunto de la base de datos relacional a un almacén de datos NoSQL como DynamoDB.

Moviendo un subconjunto de datos a Amazon EC2 o Amazon RDS

La parte más fácil de este enfoque es identificar la parte de su base de datos que desea que no se modifique. Puede migrar esta parte de su base de datos al mismo motor de base de datos en Amazon RDS, o puede ejecutarla como una base de datos autoadministrada en Amazon EC2.

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

Para determinar qué parte de su base de datos se debe dejar sin cambios, considere estas preguntas:

• ¿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?
• ¿Se escribió un código de procedimiento 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.
• ¿Se escribió el código de la aplicación y la interfaz de usuario para este conjunto de datos que es difícil de cambiar?
• ¿Su aplicación emite 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 respondió «Sí» a todas o a la mayoría de las preguntas anteriores sobre un subconjunto de su base de datos relacional, ese subconjunto es más adecuado para migrar a la base de datos relacional en Amazon RDS o Amazon EC2. El subconjunto de datos que usted identifica permanece sin cambios y puede ser la mayoría, digamos, del 50 – 60 por ciento de su base de datos. Para determinar el tamaño de este subconjunto de datos, los administradores o desarrolladores de la base de datos pueden consultar el diccionario de datos de la base de datos para obtener el tamaño de los datos que se migrarán a Amazon RDS o Amazon EC2.

Para migrar los datos, puede usar las herramientas nativas de su motor de base de datos, AWS DMS, AWS Herramienta de Conversión de Esquema o herramientas de terceros. AWS DMS soportan migraciones de bases de datos homogéneas y heterogéneas. Admiten migraciones de carga completa, de una sola vez o migraciones en curso de bases de datos para ayudar a reducir el tiempo de inactividad de la aplicación. Para obtener más información sobre cómo migrar las soluciones de bases de datos comerciales hacia AWS utilizando herramientas nativas y AWS DMS, consulte Prácticas Recomendadas para el Servicio de Migración de Bases de Datos de AWS.

Moviendo grandes objetos de una base de datos relacional a Amazon S3

Muchos clientes diseñan aplicaciones que almacenan Datos de Objetos Grandes de Caracteres (CLOB) y Objetos Binarios Grandes (BLOB) en tablas de bases de datos relacionales. Es natural hacer esto porque la mayoría de las soluciones de bases de datos relacionales permiten estos tipos de datos y brindan formas de almacenar y acceder a objetos grandes (LOB).

Almacenando CLOBs y BLOBs en una base de datos incluye los siguientes beneficios:

• Consistencia en un punto de tiempo determinado. Cuando restaura una base de datos en un tiempo específico, todos los datos y objetos vuelven al mismo estado que tenían anteriormente.
• Facilidad de acceso.
• Controles de seguridad y acceso.

Si su aplicación está generando estos LOBs en gigabytes por segundo, almacenar y procesar los datos en una base de datos relacional puede consumir una gran cantidad de rendimiento de red, I/O de disco, CPU y memoria. Para las aplicaciones que pueden tolerar la latencia transaccional en segundos mientras se almacenan y recuperan objetos grandes, la descarga de estos datos a Amazon S3 puede mejorar el desempeño y la disponibilidad. Amazon S3 le 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, puede comenzar poco a poco y hacer crecer su aplicación como desee, sin comprometer el rendimiento ni la confiabilidad.

Para lograr la coherencia de un punto en el tiempo para los LOBs, debe modificar la lógica de su aplicación para almacenar el ID de versión del objeto modificado en Amazon S3 junto con la transacción en la base de datos relacional. Este cambio en la aplicación es mínimo en comparación con los ahorros de TCO y la mejora del rendimiento de la aplicación en su totalidad.

Moviendo datos históricos a Amazon S3

Muchas bases de datos grandes contienen datos históricos que no se leen a menudo pero que consumen ciclos de almacenamiento y CPU. Es posible que necesite conservar estos datos, por ejemplo, para fines de cumplimiento y normatividad. En lugar de mantener estos datos en una base de datos relacional, puede crear carpetas de archivos a partir de los datos en su base de datos relacional durante un período determinado y descargarlos a Amazon S3 o Amazon S3 Glacier.

Cuando su aplicación necesite acceder a los datos en esas carpetas de archivo, puede usar las características de Amazon S3, como Amazon S3 Select o Amazon S3 Glacier Select. Este enfoque puede reducir significativamente los costos de almacenamiento y recuperación de datos, al mismo tiempo que proporciona durabilidad (protección de datos a largo plazo) del 99.999999999% y disponibilidad (tiempo de actividad del sistema) del 99.99% durante un año determinado.

Moviendo un subconjunto de datos a un almacén de datos NoSQL como DynamoDB

Como última parte de la estrategia general, considere DynamoDB para almacenar un subconjunto de datos de su base de datos relacional. Amazon DynamoDB es una base de datos NoSQL totalmente gestionada que admite estructuras de datos clave y de valores y documentos. DynamoDB le permite descargar las cargas administrativas de operar y escalar una base de datos distribuida para que no tenga que preocuparse por el aprovisionamiento de hardware, instalación y configuración, replicación, parches de software o escalado de clústeres del hardware.

Para identificar los datos que se pueden almacenar en un almacén de datos NoSQL como DynamoDB, tenga en cuenta los siguientes factores:

• ¿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?
• ¿Necesita un almacén de datos que soporte transacciones ACID?
• ¿Necesita replicar las tablas de la base de datos globalmente (en otras palabras, a través de las Regiones de AWS) para servir a su base de usuarios global con baja latencia?

Si responde «Sí» a todas o la mayoría de las preguntas anteriores para un subconjunto de su base de datos relacional, entonces ese subconjunto de datos es más adecuado para migrar a un almacén de datos NoSQL como Amazon DynamoDB.

Además de las consideraciones anteriores, no mueva los datos a un almacén de datos NoSQL que:

• Se agrega de muchas tablas para 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.
• Requeriría cantidades significativas de cambio en la capa de aplicación.

Comprendiendo la condición de su almacén de datos lo ayuda a decidir qué datos mover al almacén de datos NoSQL y qué datos debe continuar almacenando en una base de datos relacional. Después de tomar la decisión de mover los datos relevantes a un almacén de datos NoSQL, el diseño de un modelo de datos en DynamoDB es clave para el rendimiento con el crecimiento futuro de los datos. DynamoDB distribuye datos en una tabla a través de múltiples particiones en diferentes servidores físicos. Estos datos se distribuyen según el valor hash (firma digital) de la clave principal (la clave de partición) de una tabla en DynamoDB. Dependiendo del patrón de lectura/escritura de datos, debe seleccionar una clave de partición que le permita a DynamoDB distribuir sus datos de manera uniforme entre las particiones. Esto mejora el rendimiento de lectura/escritura de sus tablas. Para obtener más información sobre cómo elegir la clave de partición correcta en DynamoDB, consulte Cómo elegir la clave de partición adecuada de DynamoDB (disponible en inglés).

Después de completar el diseño de su tabla de DynamoDB, puede usar AWS DMS para migrar datos de su base de datos relacional a DynamoDB. Para obtener más información, consulte el Servicio de migración de bases de datos de AWS y Amazon DynamoDB: lo que necesita saber (disponible en inglés).

Además de los beneficios mencionados anteriormente en esta sección, al migrar un subconjunto de datos de su base de datos relacional a DynamoDB, solo paga por la capacidad de lectura/escritura que aprovisiona para su tabla y logra ahorros de costos significativos. Además, ahora puede usar DynamoDB bajo demanda, lo que permite atender miles de solicitudes por segundo en una tabla de DynamoDB sin planificación de capacidad. Para obtener más información, consulte los precios de Amazon DynamoDB.

Resumen

En esta publicación del blog, leyó sobre cómo dividir sus bases de datos monolíticas en almacenes de datos especialmente diseñados a medida que migra sus bases de datos a AWS. Puede obtener importantes ahorros en costos de licenciamiento e infraestructura, así como una mejor disponibilidad al identificar el almacén de datos adecuado para sus datos.

Si tiene comentarios sobre esta publicación de blog, envíelos a la sección de Comentarios a continuación. Si tiene preguntas sobre la implementación de las soluciones aquí, también puede dejarlas en la sección Comentarios.

Acerca de los autores

Ejaz Sayyed es un arquitecto de soluciones asociado con el equipo Global System Integrator en Amazon Web Services. Sus áreas de enfoque incluyen los servicios de bases de datos de AWS, así como las migraciones de bases de datos y almacenes de datos en AWS.

Karthik Thirugnanasambandam es un arquitecto de soluciones asociado en Amazon Web Services. Trabaja con grandes integradores de sistemas globales en la adopción de AWS Cloud. Es un entusiasta de DevOps y serverless. Cuando no está trabajando, le gusta leer y pasar tiempo con su familia.