Particionando bases de datos horizontalmente (sharding) con Amazon RDS

Lei Zeng, Ingeniera de Bases de Datos Senior de AWS

Sharding, también conocido como particionamiento horizontal de bases de datos, es un enfoque popular de escalamiento horizontal para bases de datos relacionales. Amazon Relational Database Service (Amazon RDS) es un servicio de base de datos relacional administrado que proporciona excelentes funciones para facilitar el uso de sharding en la nube. En esta publicación, describo cómo utilizar Amazon RDS para implementar una arquitectura de base de datos horizontalmente particionada (sharded) a fin de lograr alta escalabilidad, alta disponibilidad y tolerancia a errores para el almacenamiento de datos. Analizo consideraciones técnicas para el diseño de esquemas de bases de datos y métricas de monitoreo al implementar Amazon RDS como una partición horizontal (shard) de base de datos. También describo los desafíos asociados al re-particionamiento (resharding) y destaco las soluciones de escalamiento vertical y horizontal de Amazon RDS disponibles con solo pulsar un botón.

Arquitectura de bases de datos particionada (sharded)

El particionamiento horizontal (sharding) es una técnica que divide los datos en subconjuntos más pequeños y los distribuye entre varios servidores de bases de datos separados físicamente. Cada servidor se denomina “shard” de base de datos. Todos los shards de base de datos suelen tener el mismo tipo de hardware, motor de base de datos y estructura de datos para generar un nivel de rendimiento similar. Sin embargo, no se conocen entre sí, que es la característica clave que diferencia sharding de otros enfoques de escalamiento horizontal, como la replicación o clústeres de bases de datos.

Este modelo nada-compartido (share-nothing) ofrece a esta arquitectura de base de datos horizontalmente particionada fortalezas únicas en cuanto a escalabilidad y tolerancia a fallas. No hay necesidad de administrar las comunicaciones y las disputas por recursos entre los miembros de la base de datos distribuida. Las complejidades técnicas y gastos de sobrecarga que implica hacerlo no existen. Si un shard de base de datos tiene un problema de hardware o experimenta un failover, ningún otro shard en la solución se verá afectado porque hay un único punto de falla que está físicamente aislado. La partición horizontal (sharding) tiene el potencial de aprovechar tantos servidores de bases de datos como desee, siempre que haya muy poca latencia proveniente de la lógica de asignación de datos y enrutamiento que reside en la aplicación.

Sin embargo, el modelo nada-compartido (share-nothing) también introduce un inconveniente inevitable de la partición horizontal de bases de datos: los datos que se distribuyen en diferentes shards de bases de datos están separados. La consulta para leer o unir datos de múltiples shards de base de datos debe estar especialmente diseñada. Por lo general se incurre en una latencia más alta que su homólogo que se ejecuta en un solo fragmento (shard). La incapacidad de ofrecer una imagen coherente y global de todos los datos limita la arquitectura de base de datos particionada horizontalmente a la hora de desempeñar un papel activo en el entorno de procesamiento analítico en línea (OLAP), donde las funciones analíticas de datos se realizan normalmente en todo el conjunto de datos.

En un entorno de procesamiento de transacciones en línea (OLTP), donde el alto volumen de escrituras o transacciones puede ir más allá de la capacidad de una sola base de datos y la escalabilidad es motivo de preocupación, siempre vale la pena evaluar sharding como una alternativa. Con la llegada de Amazon RDS, la configuración y las operaciones de la base de datos se han automatizado en gran medida. Esto hace que trabajar con una arquitectura de base de datos distribuida sea una tarea mucho más fácil. Amazon RDS ofrece un conjunto de motores de bases de datos, incluidos Amazon RDS para MySQL, MariaDB, PostgreSQL, Oracle, SQL Server y Amazon Aurora. Puede usar cualquiera de estos elementos como el componente básico de un shard de base de datos en una arquitectura de base de datos particionada horizontalmente (sharded).

Echemos un vistazo a un ejemplo de una arquitectura de base de datos particionada horizontalmente (sharded) que se ha creado con Amazon RDS. Desde el punto de vista de una solución desplegada en la nube de AWS, su posición en la ruta del flujo de datos tiene varias características (ilustradas en el siguiente diagrama).

Los datos se introducen en el sistema a través de aplicaciones web que se alojan en un grupo de instancias de Amazon EC2 con la función Auto Scaling.
El almacenamiento de datos está diseñado en capas donde el entorno OLTP está separado del entorno OLAP para cumplir con los diferentes requisitos comerciales y de custodia de datos.
El entorno OLTP utiliza particionamiento horizontal (sharding) de bases de datos y consiste en un grupo de bases de datos creadas con Amazon RDS para ofrecer alta escalabilidad a fin de satisfacer la creciente demanda de rendimiento de escritura. Cada shard de base de datos se crea con alta disponibilidad mediante una base de datos independiente implementada con la función Multi-AZ. Nota: Si elige un clúster de base de datos Aurora para crear un shard de base de datos, también puede lograr alta disponibilidad configurando una réplica de lectura con la instancia principal.
Los datos se extraen del entorno OLTP al entorno OLAP según una programación calendarizada. Puede utilizar Amazon Redshift para incluir datos de todos los shards de base de datos y crear un conjunto de datos global coherente en el tiempo para las funciones de análisis de datos. Los datos agregados se envían a Amazon S3 para intercambio de datos, otros servicios de análisis y almacenamiento a largo plazo.

Particionamiento horizontal y diseño de esquemas de bases de datos

El requisito previo para implementar una arquitectura de base de datos distribuida (sharded) es particionar los datos horizontalmente y distribuir las particiones de datos entre los shards de la base de datos. Puedes usar varias estrategias para particionar una tabla, como la partición por listas, la partición por rangos o la partición por una función hash. Puede permitir que cada shard de base de datos aloje una o más particiones de tabla en el formato de tablas separadas.

El siguiente diagrama ilustra un ejemplo de partición horizontal de la tabla Invoice utilizando customer_id como la clave de partición.

Cuando hay varias tablas involucradas y enlazadas por relaciones de claves foráneas (foreign keys), puede lograr la partición horizontal mediante el uso de la misma clave de partición en todas las tablas involucradas. Los datos que se extienden por las tablas pero que pertenecen a una clave de partición se distribuyen a un shard de base de datos. El siguiente diagrama muestra un ejemplo de partición horizontal en un conjunto de tablas.

Las técnicas de diseño de datos utilizadas son las siguientes:

Cada shard de base de datos contiene una tabla de asignación de claves de partición para almacenar las claves de partición que residen en ese shard. Las aplicaciones leen esta tabla de todos los shards para construir la lógica de mapeo de datos que asigna una clave de partición a un shard de base de datos. A veces, las aplicaciones pueden usar un algoritmo predefinido para determinar en qué shard de base de datos se encuentra una clave de partición y, por lo tanto, se puede omitir esta tabla.
La clave de partición (customer_id en este ejemplo) se añade a todas las demás tablas como punto de aislamiento de datos. Esta clave influye directamente en la distribución de datos y cargas de trabajo a diferentes shards de bases de datos. Las consultas destinadas a una sola partición incluyen la clave de partición para que la lógica de enrutamiento de datos en la aplicación pueda utilizarla para asignarla a un shard de base de datos y enrutar las consultas en consecuencia.
Las claves primarias tienen valores de clave únicos en todos los shards de la base de datos para evitar colisiones de claves cuando los datos se migran de un shard a otro o cuando los datos se fusionan en el entorno OLAP. Por ejemplo, la clave primaria de la tabla Factura, invoice_id, utiliza números intercalados y tiene los dos últimos dígitos reservados para shard_id. Otra práctica común es utilizar un GUID o UUID como claves primarias.
La columna con el tipo de datos timestamp se puede definir en las tablas como el punto de consistencia de los datos. Esta columna actúa como criterio para combinar datos de todos los shards de la base de datos en la vista global cuando es necesario. Por ejemplo, cuando los datos se extraen al entorno OLAP, la columna creation_date de la tabla Factura se utiliza como filtro en la consulta de extracción para especificar un intervalo de tiempo consistente para todos los shards.

Una arquitectura de base de datos particionada horizontalmente (sharded) bien diseñada permite que los datos y la carga de trabajo se distribuyan de manera uniforme en todos los shards de base de datos. Las consultas que aterrizan en diferentes shards pueden alcanzar el nivel esperado de rendimiento de forma consistente. El creciente número de particiones de datos en un shard aumentaría el consumo de recursos de un motor de base de datos, creando puntos de contención y cuellos de botella incluso en hardware a gran escala. Para decidir cuántas particiones de datos usar por shard, normalmente se puede lograr un equilibrio entre el compromiso de optimizar el rendimiento de las consultas y el objetivo de consolidar, de obtener un mejor uso de los recursos para reducir los costos

Al implementar instancias de Amazon RDS como shards de base de datos, también debe tener en cuenta el tipo de motor de base de datos, la clase de instancia de base de datos y el almacenamiento configurado para esa instancia RDS. Para ayudarlo a administrar fácilmente las configuraciones de bases de datos, Amazon RDS proporciona un grupo de parámetros de base de datos (parameter group). Este grupo de parámetros contiene el conjunto deseado de valores de configuración que se pueden aplicar a todos los shards de la base de datos de forma consistente.

Monitoreando escalabilidad

Las métricas de monitoreo de un shard (como el uso de recursos del sistema o el rendimiento de la base de datos) se consideran más significativas en el contexto de una imagen global en la que se puede comparar un shard con otros para verificar si hay un punto caliente en el sistema. También es beneficioso establecer un período de retención adecuado para monitorear los datos. Se puede utilizar esta información histórica para analizar tendencias y planificar la capacidad para ayudar al sistema a adaptarse a cambios.

Como servicio administrado, Amazon RDS recopila automáticamente los datos de monitoreo y los publica en Amazon CloudWatch. CloudWatch proporciona una vista unificada de las métricas a nivel de base de datos y sistema. Algunas métricas son genéricas para todas las bases de datos, mientras que otras son específicas de un motor de base de datos determinado. Para obtener una lista completa de métricas, consulte la documentación de Amazon RDS y Amazon Aurora.

Siempre recomiendo métricas que monitorean el uso general de los recursos del sistema, como CPUUtilization, FreeableMemory, ReadIOPS, WriteIOPS y FreeStorageSpace. Estas métricas son indicadores de si el uso de recursos en un shard de base de datos está dentro de su capacidad y cuánto espacio queda disponible para el crecimiento. El consumo de recursos del sistema es un factor importante para justificar que una arquitectura de base de datos particionada horizontalmente necesita ampliarse aún más o, por el contrario, consolidarse.

El siguiente es un ejemplo de un dashboard CloudWatch que ofrece gran visibilidad de la arquitectura de base de datos particionada horizontalmente. Reúne datos de métricas históricas y en tiempo real de todos los shards de la base de datos en un solo gráfico

Cuando un shard de base de datos tiene un uso elevado de recursos del sistema y requiere más capacidad de cómputo, la solución puede escalarse verticalmente u horizontalmente. Amazon RDS ofrece una opción de escalamiento vertical con solo pulsar un botón. Puede usar esta opción para modificar una clase de instancia de base de datos a hardware más grande con más CPU y RAM, o modificar el almacenamiento de la instancia de base de datos para obtener más espacio de almacenamiento y una mayor capacidad de IOPS. Las opciones de clases de instancias disponibles pueden variar según los diferentes motores de base de datos o versiones de bases de datos requeridas. La consola de administración de AWS es un buen lugar para comprobarlo.

Si elige Amazon RDS para MySQL o PostgreSQL para crear un shard de base de datos, hay otra opción de escalamiento vertical: migrar a un clúster de base de datos de Amazon Aurora. Un clúster de base de datos Aurora puede constar de más de una instancia de base de datos sobre volúmenes de almacenamiento en clúster para ofrecer un rendimiento y una capacidad de IOPS superiores a los de una instancia de base de datos de Amazon RDS. Amazon RDS ofrece una opción de pulsar un botón para crear una réplica de lectura en Aurora. Esta opción configura el proceso de replicación para migrar datos de una instancia de base de datos de Amazon RDS para MySQL o PostgreSQL a una réplica de lectura de Aurora. Cuando se completa la migración de datos, la réplica de lectura de Aurora se puede convertir en un clúster de base de datos Aurora independiente.

Resharding

La opción de escalado horizontal para un shard de base de datos se conoce como resharding, lo que significa volver a hacer sharding. En un sentido amplio, el resharding también puede referirse a todos los procedimientos que pretenden ajustar el número de particiones en una arquitectura de base de datos particionada horizontalmente. Estos procedimientos incluyen añadir un nuevo shard, dividir un shard en varios shards o fusionar varios shards en uno solo. A pesar de su formato diferente, esos procedimientos deben realizar esencialmente el mismo tipo de operación: migrar los datos existentes de un shard a otro. En una base de datos de producción donde los datos se acceden y cambian constantemente, la migración de datos con un tiempo de inactividad mínimo siempre es un desafío para el resharding.

Amazon RDS ha hecho un gran esfuerzo para facilitar el resharding! En Amazon RDS para MySQL, MariaDB o PostgreSQL, Amazon RDS ofrece una opción de escalado horizontal con solo pulsar un botón (réplicas de lectura) para dividir una base de datos independiente en varias nuevas. El siguiente diagrama muestra un flujo de trabajo de ejemplo de resharding que utiliza una réplica de lectura como técnica de replicación de datos para migrar datos entre bases de datos.

La réplica de lectura se crea para replicar datos de la base de datos maestra de forma continua
La base de datos maestra detiene las actividades de escritura para que la réplica de lectura pueda sincronizarse y convertirse en una nueva base de datos independiente. Durante este tiempo, la lógica de asignación y enrutamiento en la aplicación actualiza el estado de varias particiones de datos en la base de datos maestra para que sean de solo lectura.
La lógica de asignación de datos y enrutamiento se modifica para enrutar las conexiones a la nueva base de datos.

Si elige un clúster de base de datos de Amazon Aurora para crear un shard de base de datos, sus réplicas de lectura comparten los volúmenes de almacenamiento con la instancia principal. Por lo tanto, no se pueden usar réplicas de lectura para replicar datos entre clústeres de Aurora. En cambio, Amazon RDS proporciona la función de clonación de base de datos para crear un nuevo clúster de base de datos Amazon Aurora con los mismos datos que la base de datos de origen. Para un clúster de base de datos Aurora MySQL, también hay una opción para configurar la replicación de MySQL para replicar sus datos en otro clúster de base de datos Aurora MySQL nuevo.

Además de utilizar las tecnologías de bases de datos existentes para replicar datos, el resharding también puede aprovechar otras herramientas para migrar datos entre shards de bases de datos, incluidos AWS Database Migration Service (AWS DMS) o procesos de extracción de datos definidos por el usuario. El siguiente diagrama es un ejemplo de un flujo de trabajo de resharding basado en herramientas que migra una partición de datos a la vez.

La herramienta de migración de datos está configurada para replicar una partición de datos de un shard de base de datos a otro. La lógica de asignación y enrutamiento en la aplicación actualiza el estado de la partición de datos para que sea de solo lectura. La herramienta de migración de datos puede sincronizar los datos entre los dos shards de la base de datos.
Después de que los datos están sincronizados, la lógica de asignación y enrutamiento de datos en la aplicación actualiza la asignación y el estado de la partición de datos para que se active en el nuevo shard de base de datos.

El método de resharding basado en herramientas tiene flexibilidad porque cada partición de datos se puede migrar de forma individual. Mientras se migra una partición de datos, pasa al modo de solo lectura y las aplicaciones pueden seguir leyendo sus datos. Otras particiones de datos permanecen accesibles tanto para lectura como para escritura, y se puede garantizar la disponibilidad de la arquitectura de base de datos particionada horizontalmente.

El método de resharding basado en bases de datos completas coloca el tiempo de inactividad de las actividades de escritura en varias particiones de datos de un shard de base de datos cuando se trata de crear una nueva base de datos. Una vez que la nueva base de datos está activa, contiene todas las particiones de datos replicadas de la base de datos original, aunque solo se utilizarán algunas de ellas en ese shard. Por lo tanto, tendrá que limpiar los datos duplicados.

Resumen

En este blog, leyó sobre sharding como un enfoque para que las bases de datos relacionales logren una alta escalabilidad. Aprendió sobre un caso de uso de ejemplo que utiliza Amazon RDS para implementar una arquitectura de base de datos particionada horizontalmente en la nube y cómo encaja en las cargas de trabajo analíticas y el almacenamiento de datos a largo plazo. También aprendió sobre varias funciones que proporciona RDS para administrar, monitorear, escalar vertical y horizontalmente los shards de bases de datos de una manera altamente automatizada.

Espero que esta publicación le haya dado una mejor comprensión de sharding y de lo fácil que es implementar esta técnica en la nube de AWS. Si tiene alguna pregunta, no dude en dejar un comentario a continuación.

Este articulo fue traducido de Blogs AWS en Inglés .

Acerca del autor

Lei Zeng es una ingeniera de bases de datos senior de AWS radicada en Irvine, California.

Traductor

Camilo Leon es un Arquitecto de Soluciones Principal especializado en bases de datos en Amazon Web Services radicado en San Francisco. Camilo Trabaja con clientes de AWS para proporcionar orientación y asistencia técnica en servicios de bases de datos relacionales, ayudándoles a mejorar el valor de sus soluciones cuando utilizan AWS.

Blog de Amazon Web Services (AWS)