Sharding o fragmentación de bases de datos: qué es, ventajas y cuándo aplicarlo

Escalar sin control una base de datos relacional es igual a cuello de botella asegurado. Para evitar este tipo de problemas existen estrategias como el sharding o fragmentación de bases de datos, que permite dividir una base de datos grandes en particiones más pequeñas para así mejorar su rendimiento, disponibilidad y escalabilidad.

En este artículo explicaremos qué es el sharding, cómo funciona, sus ventajas y desventajas, y los diferentes tipos de estrategias que podemos implementar. También veremos algunos ejemplos de sharding y analizaremos cuándo es el momento adecuado para considerar implementar esta técnica en nuestras aplicaciones.

¿Qué es el sharding?

La fragmentación o sharding de bases de datos es un patrón de arquitectura de almacenamiento de datos que permite subdividir un gran conjunto de datos en varios más pequeños.

Estos fragmentos, conocidos como shards, trabajan juntos como un único sistema distribuido, pero físicamente están separados, cada uno con una parte de los datos y operando de manera independiente.

Las bases de datos empresariales pueden alcanzar varios terabytes e incluso petabytes, información, lo que eventualmente genera problemas de rendimiento si no se gestiona adecuadamente.

El sharding permite distribuir esta carga entre múltiples servidores o instancias, evitando que una sola máquina tenga que procesar todas las solicitudes.

Es una técnica de escalado horizontal. Mientras el escalado vertical consiste en añadir más recursos a un único servidor (por ejemplo, más CPU o RAM), el sharding es una técnica de escalado horizontal que distribuye la carga entre múltiples servidores, permitiendo que el sistema maneje más datos y tráfico sin degradar el rendimiento.

¿Cómo funciona el sharding en bases de datos?

Podemos pensar en el sharding como una cola del supermercado. Imagina que, en lugar de tener una única cola con todos los clientes del supermercado, tienes múltiples cajas con su propia cola de clientes.

Cada caja maneja solo una parte del total de clientes, lo que hace que el proceso sea más rápido y eficiente. En una base de datos, cada caja registradora sería un shard y los clientes serían los datos que se distribuyen entre estos shards.

https://www.youtube.com/watch?v=XP98YCr-iXQ

De esta forma, cuando se fragmenta una base de datos, cada shard contiene una porción de los datos totales. Por ejemplo, si tenemos una base de datos de usuarios, podríamos fragmentarla por ubicación geográfica: un shard para usuarios de América, otro para Europa, otro para Asia, etc. Cuando un usuario hace una consulta, el sistema la dirige automáticamente al shard correspondiente, reduciendo el tiempo de respuesta y distribuyendo la carga.

En cuanto a la arquitectura, se conoce como shared-nothing (SN) porque cada shard tiene sus propios recursos computacionales, almacenamiento y memoria, y no comparte ningún recurso con otros shards. Esto contrasta con arquitecturas donde hay recursos compartidos entre nodos.

En un sistema shared-nothing, cada nodo es independiente y autosuficiente, lo que facilita la escalabilidad horizontal y mejora la resistencia a fallos del sistema.

¿Qué tipos de sharding existen para bases de datos?

Como dividir la base de datos en diferentes fragmentos es una de las principales decisiones a la hora de “hacer sharding”. Existen varias formas de hacerlo y cada enfoque tiene tantos sus ventajas como sus desventajas. Habrá que seleccionar el más correcto según los requisitos del proyecto, los objetivos del negocio, los patrones de acceso o los planes de crecimiento.

Sharding a distancia/dinámico

El sharding dinámico es una técnica donde los datos se fragmentan automáticamente según patrones de acceso y carga del sistema. A diferencia de otros métodos, los límites entre shards pueden ajustarse dinámicamente para mantener un rendimiento óptimo.

Esta técnica funciona tomando un campo del registro como entrada y, en función de un rango predefinido, asigna ese registro a la partición adecuada.

El sistema utiliza una tabla de búsqueda o un servicio centralizado que está disponible para todas las consultas o escrituras, permitiendo localizar rápidamente el shard donde se encuentra la información.

La elección de la clave de fragmento (el campo usado para decidir dónde colocar los datos) y los rangos asociados son fundamentales para que este tipo de sharding sea efectivo. Una mala elección resultará en fragmentos desequilibrados donde algunos shards reciben mucha más carga que otros, lo que degrada el rendimiento general del sistema.

Para que una clave de fragmento sea eficaz, debe tener dos características principales:

• Alta cardinalidad: se refiere a la cantidad de valores únicos posibles para esa clave. Por ejemplo, si usamos «género» como clave de fragmento, solo tendríamos unos pocos shards posibles, lo cual es insuficiente para una buena distribución. En cambio, un ID de usuario ofrece millones de valores posibles.
• Distribución equilibrada: los valores de la clave deben estar bien distribuidos para evitar concentraciones. Por ejemplo, si el 95% de los registros tienen un mismo valor de clave, entonces ese 95% terminaría en un solo shard, creando un cuello de botella.

Esta técnica permite que el sistema se adapte automáticamente a cambios en los patrones de acceso, redistribuyendo datos entre shards según sea necesario para mantener el rendimiento óptimo a lo largo del tiempo.

Sharding basado en hash

En este enfoque, se aplica una función hash a la columna seleccionada (la clave de sharding) para determinar en qué fragmento se almacenará cada registro. Por ejemplo, podríamos calcular el hash del ID de usuario y utilizar el resultado para asignar cada usuario a un shard específico.

Este método distribuye los datos de manera uniforme entre los shards, lo que ayuda a balancear la carga. Sin embargo, puede dificultar las consultas por rango, ya que registros consecutivos pueden estar en diferentes shards.

El sharding basado en hash proporciona una buena distribución, pero tiene limitaciones cuando necesitamos realizar búsquedas por rango o cuando la distribución de datos cambia con el tiempo, ya que podría requerir rebalanceos costosos.

Sharding basado en rangos

Este tipo de sharding divide los datos en rangos contiguos basados en el valor de una columna clave.

Por ejemplo, se podrían distribuir los usuarios según el rango alfabético de sus apellidos: A-G en un shard, H-M en otro, etc. Esta estrategia facilita las consultas por rangos, ya que los datos relacionados suelen estar en el mismo shard.

Sin embargo, el sharding por rangos puede llevar a una distribución desigual si los datos no están uniformemente distribuidos en los rangos definidos. Por ejemplo, si tenemos más usuarios con apellidos que comienzan con ‘S’ que con otras letras, ese shard específico tendrá una carga desproporcionada.

Sharding geográfico o geosharding

Este enfoque divide los datos según la ubicación geográfica. Por ejemplo, los usuarios de América del Norte podrían estar en un shard, los de Europa en otro y los de Asia en un tercero.

Esto optimiza la latencia, ya que los datos se almacenan más cerca de donde se accederán con mayor frecuencia, mejorando la velocidad de respuesta para los usuarios finales.

El sharding geográfico es especialmente útil para aplicaciones multinacionales que necesitan cumplir con regulaciones regionales sobre almacenamiento de datos, como el GDPR en Europa. Sin embargo, puede complicarse si los usuarios viajan con frecuencia o si la aplicación necesita acceder a datos de diferentes regiones simultáneamente.

Sharding basado en directorios o directory-based sharding

Esta estrategia utiliza una tabla o servicio de directorio centralizado que mapea los datos a sus respectivos shards. El directorio actúa como una capa de abstracción que rastrea qué datos están en qué shard. Cuando llega una consulta, primero se consulta al directorio para determinar en qué shard se encuentra la información requerida.

La ventaja principal de este enfoque es su flexibilidad, ya que permite rebalancear los datos entre shards sin cambiar la lógica de la aplicación. Sin embargo, el directorio centralizado puede convertirse en un único punto de fallo y un potencial cuello de botella si no se diseña adecuadamente para manejar altas cargas de trabajo.

Sharding basado en entidad/relación

Este método divide los datos según sus relaciones y entidades, agrupando elementos relacionados en el mismo shard. Por ejemplo, se podrían tener todos los pedidos y detalles de un cliente específico en el mismo fragmento, lo que optimiza las consultas que involucran múltiples tablas relacionadas.

El sharding basado en entidad/relación mejora el rendimiento de consultas complejas que acceden a datos relacionados, ya que reduce la necesidad de unir (join) datos entre diferentes shards. Sin embargo, requiere un análisis cuidadoso de las relaciones entre entidades y puede ser complicado implementar cuando las relaciones entre datos cambian con el tiempo.

Ventajas del sharding de bases de datos

El sharding de bases de datos ofrece grandes ventajas que lo convierten en una solución atractiva para aplicaciones que manejan grandes volúmenes de datos. Entre los beneficios más significativos encontramos:

• Mejor rendimiento escritura/lectura: al distribuir la carga entre múltiples servidores, se reducen los tiempos de respuesta y se aumenta la velocidad de procesamiento. Cada shard maneja menos datos, lo que permite consultas y escrituras más rápidas y eficientes.
• Mayor disponibilidad: con un sistema distribuido, si un shard falla, el resto puede seguir funcionando, minimizando el impacto en la disponibilidad general del sistema. Esto proporciona mayor resistencia ante fallos y reduce los tiempos de inactividad.
• Escalabilidad horizontal: el sharding permite añadir más servidores (shards) cuando se necesita más capacidad, en lugar de actualizar continuamente el hardware de un único servidor. Esto hace que el crecimiento sea más flexible y económico a largo plazo.
• Optimización geográfica: En el caso del geosharding, permite almacenar datos más cerca de los usuarios que los utilizan con mayor frecuencia, reduciendo la latencia y mejorando la experiencia del usuario.
• Cumplimiento normativo: Facilita el cumplimiento de regulaciones que exigen que ciertos datos se almacenen en ubicaciones geográficas específicas.

Desventajas del sharding

A pesar de sus ventajas, el sharding también presenta algunos desafíos importantes que deben tenerse en cuenta antes de implementarlo:

• Complejidad operativa: el mantenimiento de múltiples shards requiere una gestión más compleja que una base de datos única. Los procesos de backup, recuperación y monitoreo se vuelven más complicados.
• Joins entre shards: las consultas que requieren datos de múltiples shards pueden volverse extremadamente costosas en términos de rendimiento, ya que los joins deben realizarse a nivel de aplicación.
• Latencia: la comunicación entre shards puede introducir latencia adicional, especialmente en sistemas distribuidos geográficamente. Estas demoras pueden afectar el rendimiento general si no se gestionan adecuadamente.
• Costes: la implementación y mantenimiento de una arquitectura sharding puede resultar costosa, tanto en términos de infraestructura como de desarrollo. Es necesario evaluar si los beneficios de rendimiento justifican la inversión adicional.
• Consistencia de datos: mantener la consistencia entre diferentes shards puede ser un desafío, especialmente en sistemas que requieren transacciones que afectan a múltiples fragmentos.

Ejemplos reales de Sharding: Netflix, Uber o Amazon

• Netflix: inicialmente tenía una base de datos Oracle que no pudo escalar cuando su número de usuarios empezó a crecer. Trasladó la mayoría de sus datos a la nube de AWS, fragmentando su base de datos por ID de usuario usando Cassandra y DynamoDB. Además, la replicó en distintas regiones para garantizar una alta disponibilidad.
• Uber: inició su negocio con una base de datos y un backend con arquitectura monolítica. Su explosión global los obligó a migrar a una arquitectura de microservicios con bases de datos fragmentadas por regiones geográficas. Ahora utilizan un sistema de sharding basado en rangos para manejar millones de viajes simultáneos en diferentes ciudades del mundo.
• Amazon: en sus inicios todo empezó con una base de datos única que unificaba usuarios, productos, pedidos y pagos. En poco tiempo esta infraestructura resultó imposible de escalar, así que la dividió en microservicios con sus propios almacenes de datos, fragmentando a su vez por ID de pedido o de cliente, por ejemplo.

¿Cuándo y cómo implementar sharding de bases de datos? 7 señales

Implementar sharding en una base de datos es una decisión importante que debe tomarse solo cuando realmente se necesita. Hacer sharding sin ningún motivo no tiene sentido, al igual que no hacerlo para poder escalar nuestros sistemas eficazmente. Aquí tienes 7 señales que indican que es el momento adecuado para considerar el sharding:

1. Degradación del rendimiento: si notas que tus consultas van cada vez más lentas a pesar de optimizar índices y consultas, puede ser una señal de que tu base de datos ha crecido demasiado para un solo servidor.
2. Alta concurrencia: cuando el número de operaciones concurrentes (lecturas/escrituras) supera la capacidad de tu sistema actual, causando bloqueos o tiempos de espera.
3. Volumen de datos masivo: si la cantidad de datos está creciendo exponencialmente y se aproxima a los límites de capacidad de almacenamiento o memoria de tu servidor.
4. Distribución geográfica: cuando tus usuarios están distribuidos globalmente y experimentan alta latencia al acceder a un servidor central.
5. Requisitos de alta disponibilidad: si tu aplicación necesita garantizar tiempo de actividad cercano al 100%, el sharding puede proporcionar redundancia y tolerancia a fallos.
6. Límites de escalado vertical: has llegado al punto donde añadir más CPU, RAM o almacenamiento a un único servidor ya no es económicamente viable o técnicamente posible.
7. Aislamiento de datos críticos: necesitas separar datos sensibles o críticos del resto por motivos de seguridad, cumplimiento normativo o rendimiento.

¿Cómo hacer sharding?

Existen muchas formas, pero en la actualidad una de las más sencillas es migrar tu base de datos relacional a la nube y aprovechar las opciones de sharding que ofrecen servicios como AWS RDS, Azure SQL Database o Google Cloud SQL.

Estos servicios proporcionan herramientas que simplifican la implementación y gestión del sharding, permitiéndote centrarte en definir la estrategia de fragmentación que mejor se adapte a tu caso de uso específico.

También existen bases de datos diseñadas para operar con sharding desde el principio, como MongoDB, Cassandra o CockroachDB. Estas soluciones NoSQL o NewSQL simplifican enormemente la implementación de estrategias de sharding, ya que incluyen esta funcionalidad de forma nativa en su arquitectura.

Sharding: en busca del equilibrio entre rendimiento y complejidad

El sharding de bases de datos es una poderosa herramienta para escalar sistemas que manejan grandes volúmenes de datos. Sin embargo, no es una solución universal ni debe implementarse prematuramente.

La clave está en analizar detenidamente las necesidades de tu aplicación, los patrones de acceso a datos y el crecimiento proyectado antes de decidir fragmentar tu base de datos. Es un proceso delicado que necesita de experiencia, conocimiento y profesionales preparados.

Al final, el éxito de una estrategia de sharding depende de encontrar el equilibrio entre rendimiento, complejidad operativa y coste. Con una planificación meticulosa y la estrategia correcta, el sharding puede transformar un sistema sobrecargado en una arquitectura robusta y escalable capaz de satisfacer las demandas más exigentes.

Si necesitas ayuda para optimizar tu infraestructura de datos, no dudes en contactar con nuestro equipo de expertos. Nuestros consultores pueden ayudarte a evaluar si el sharding es la solución adecuada para tu proyecto y diseñar una estrategia de implementación que minimice los riesgos y maximice beneficios.