Comprensión de la fragmentación de bases de datos

Introducción

Cualquier aplicación o sitio web que experimente un crecimiento significativo necesitará eventualmente escalar para adaptarse a los aumentos de tráfico. En el caso de las aplicaciones y sitios web basados ​​en datos, es fundamental que el escalamiento se realice de una manera que garantice la seguridad e integridad de sus datos. Puede resultar difícil predecir qué tan popular se volverá un sitio web o una aplicación o cuánto tiempo mantendrá esa popularidad, por lo que algunas organizaciones eligen una arquitectura de base de datos que les permita escalar sus bases de datos de manera dinámica.

En este artículo conceptual, analizaremos una de esas arquitecturas de bases de datos: bases de datos fragmentadas . La fragmentación ha recibido mucha atención en los últimos años, pero muchas personas no comprenden claramente qué es ni en qué situaciones puede tener sentido fragmentar una base de datos. Repasaremos qué es la fragmentación, algunos de sus principales beneficios y desventajas, y también algunos métodos de fragmentación comunes.

¿Qué es el Sharding?

La fragmentación es un patrón de arquitectura de base de datos relacionado con la partición horizontal : la práctica de separar las filas de una tabla en varias tablas diferentes, conocidas como particiones. Cada partición tiene el mismo esquema y las mismas columnas, pero también filas completamente diferentes. Asimismo, los datos almacenados en cada una son únicos e independientes de los datos almacenados en otras particiones.

Puede resultar útil pensar en la partición horizontal en términos de cómo se relaciona con la partición vertical . En una tabla particionada verticalmente, se separan columnas enteras y se colocan en tablas nuevas y distintas. Los datos contenidos en una partición vertical son independientes de los datos de todas las demás, y cada una contiene filas y columnas distintas. El siguiente diagrama ilustra cómo se puede particionar una tabla tanto horizontal como verticalmente:

La fragmentación implica dividir los datos en dos o más fragmentos más pequeños, denominados fragmentos lógicos . Los fragmentos lógicos se distribuyen luego entre nodos de base de datos separados, denominados fragmentos físicos , que pueden contener varios fragmentos lógicos. A pesar de esto, los datos contenidos en todos los fragmentos representan colectivamente un conjunto de datos lógico completo.

Los fragmentos de bases de datos ejemplifican una arquitectura de no compartir nada . Esto significa que los fragmentos son autónomos; no comparten ninguno de los mismos datos ni recursos informáticos. Sin embargo, en algunos casos, puede tener sentido replicar ciertas tablas en cada fragmento para que sirvan como tablas de referencia. Por ejemplo, supongamos que hay una base de datos para una aplicación que depende de tasas de conversión fijas para las medidas de peso. Al replicar una tabla que contiene los datos de tasa de conversión necesarios en cada fragmento, ayudaría a garantizar que todos los datos necesarios para las consultas se mantengan en cada fragmento.

A menudo, la fragmentación se implementa en el nivel de la aplicación, lo que significa que la aplicación incluye código que define a qué fragmento se deben transmitir las lecturas y escrituras. Sin embargo, algunos sistemas de administración de bases de datos tienen capacidades de fragmentación integradas, lo que le permite implementar la fragmentación directamente en el nivel de la base de datos.

Dada esta descripción general de la fragmentación, repasemos algunos de los aspectos positivos y negativos asociados con esta arquitectura de base de datos.

Beneficios de la fragmentación

El principal atractivo de fragmentar una base de datos es que puede ayudar a facilitar el escalamiento horizontal , también conocido como escalamiento horizontal . El escalamiento horizontal es la práctica de agregar más máquinas a una pila existente para distribuir la carga y permitir más tráfico y un procesamiento más rápido. Esto a menudo se contrasta con el escalamiento vertical , también conocido como escalamiento ascendente , que implica actualizar el hardware de un servidor existente, generalmente agregando más RAM o CPU.

Es relativamente sencillo tener una base de datos relacional ejecutándose en una sola máquina y escalarla según sea necesario actualizando sus recursos informáticos. Sin embargo, en última instancia, cualquier base de datos no distribuida estará limitada en términos de almacenamiento y potencia informática, por lo que tener la libertad de escalar horizontalmente hace que su configuración sea mucho más flexible.

Otra razón por la que algunos podrían elegir una arquitectura de base de datos fragmentada es para acelerar los tiempos de respuesta de las consultas. Cuando envía una consulta a una base de datos que no ha sido fragmentada, es posible que tenga que buscar en cada fila de la tabla que está consultando antes de poder encontrar el conjunto de resultados que está buscando. Para una aplicación con una base de datos grande y monolítica, las consultas pueden volverse prohibitivamente lentas. Sin embargo, al fragmentar una tabla en varias, las consultas tienen que recorrer menos filas y sus conjuntos de resultados se devuelven mucho más rápido.

La fragmentación también puede ayudar a que una aplicación sea más confiable al mitigar el impacto de las interrupciones. Si su aplicación o sitio web depende de una base de datos no fragmentada, una interrupción puede hacer que toda la aplicación no esté disponible. Sin embargo, con una base de datos fragmentada, es probable que una interrupción afecte solo a un único fragmento. Si bien esto puede hacer que algunas partes de la aplicación o el sitio web no estén disponibles para algunos usuarios, el impacto general sería menor que si fallara toda la base de datos.

Desventajas de la fragmentación

Si bien la fragmentación de una base de datos puede facilitar la escalabilidad y mejorar el rendimiento, también puede imponer ciertas limitaciones. Aquí, analizaremos algunas de ellas y por qué podrían ser motivos para evitar la fragmentación por completo.

La primera dificultad que encuentran las personas con la fragmentación es la gran complejidad de implementar correctamente una arquitectura de base de datos fragmentada. Si se hace incorrectamente, existe un riesgo significativo de que el proceso de fragmentación pueda provocar la pérdida de datos o la corrupción de las tablas. Sin embargo, incluso cuando se hace correctamente, es probable que la fragmentación tenga un impacto importante en los flujos de trabajo de su equipo. En lugar de acceder y administrar los datos desde un único punto de entrada, los usuarios deben administrar los datos en múltiples ubicaciones de fragmentación, lo que podría ser potencialmente perjudicial para algunos equipos.

Un problema que los usuarios encuentran a veces después de haber fragmentado una base de datos es que los fragmentos terminan desequilibrándose. A modo de ejemplo, supongamos que tiene una base de datos con dos fragmentos separados, uno para los clientes cuyos apellidos comienzan con las letras de la A a la M y otro para aquellos cuyos nombres comienzan con las letras de la N a la Z. Sin embargo, su aplicación atiende a una cantidad desmesurada de personas cuyos apellidos comienzan con la letra G. En consecuencia, el fragmento AM acumula gradualmente más datos que el NZ, lo que hace que la aplicación se ralentice y se bloquee para una parte significativa de sus usuarios. El fragmento AM se ha convertido en lo que se conoce como un punto de acceso de base de datos . En este caso, cualquier beneficio de fragmentar la base de datos se cancela por las ralentizaciones y las fallas. Es probable que sea necesario reparar y volver a fragmentar la base de datos para permitir una distribución de datos más uniforme.

Otro inconveniente importante es que una vez que se ha fragmentado una base de datos, puede resultar muy difícil devolverla a su arquitectura no fragmentada. Las copias de seguridad de la base de datos realizadas antes de que se fragmentara no incluirán los datos escritos desde la partición. En consecuencia, reconstruir la arquitectura no fragmentada original requeriría fusionar los nuevos datos particionados con las copias de seguridad antiguas o, alternativamente, transformar la base de datos particionada nuevamente en una única base de datos, lo que sería costoso y requeriría mucho tiempo.

Una desventaja final a tener en cuenta es que la fragmentación no es compatible de forma nativa con todos los motores de bases de datos. Por ejemplo, PostgreSQL no incluye la fragmentación automática como una característica, aunque es posible fragmentar manualmente una base de datos PostgreSQL. Hay una serie de bifurcaciones de Postgres que sí incluyen la fragmentación automática, pero a menudo se quedan atrás de la última versión de PostgreSQL y carecen de otras características. Algunas tecnologías de bases de datos especializadas (como MySQL Cluster o ciertos productos de base de datos como servicio como MongoDB Atlas) sí incluyen la fragmentación automática como una característica, pero las versiones estándar de estos sistemas de gestión de bases de datos no lo hacen. Debido a esto, la fragmentación a menudo requiere un enfoque de “creación propia”. Esto significa que la documentación para la fragmentación o los consejos para la resolución de problemas suelen ser difíciles de encontrar.

Por supuesto, estos son solo algunos aspectos generales que se deben tener en cuenta antes de fragmentar una base de datos. Puede haber muchos más inconvenientes potenciales en la fragmentación de una base de datos según el caso de uso.

Ahora que hemos cubierto algunas de las desventajas y beneficios de la fragmentación, repasaremos algunas arquitecturas diferentes para bases de datos fragmentadas.

Arquitecturas de fragmentación

Una vez que haya decidido fragmentar su base de datos, lo siguiente que debe determinar es cómo lo hará. Al ejecutar consultas o distribuir datos entrantes a tablas o bases de datos fragmentadas, es fundamental que se dirijan al fragmento correcto. De lo contrario, podría provocar la pérdida de datos o consultas extremadamente lentas. En esta sección, repasaremos algunas arquitecturas de fragmentación comunes, cada una de las cuales utiliza un proceso ligeramente diferente para distribuir datos entre fragmentos.

Fragmentación basada en claves

La fragmentación basada en claves , también conocida como fragmentación basada en hash , implica el uso de un valor tomado de datos recién escritos (como el número de identificación de un cliente, la dirección IP de una aplicación cliente, un código postal, etc.) y su inserción en una función hash para determinar a qué fragmento deben ir los datos. Una función hash es una función que toma como entrada un fragmento de datos (por ejemplo, un correo electrónico de un cliente) y genera un valor discreto, conocido como valor hash . En el caso de la fragmentación, el valor hash es un identificador de fragmento que se utiliza para determinar en qué fragmento se almacenarán los datos entrantes. En conjunto, el proceso se ve así:

Para garantizar que las entradas se coloquen en los fragmentos correctos y de manera consistente, los valores ingresados ​​en la función hash deben provenir todos de la misma columna. Esta columna se conoce como clave de fragmento . En términos simples, las claves de fragmento son similares a las claves principales en que ambas son columnas que se utilizan para establecer un identificador único para filas individuales. En términos generales, una clave de fragmento debe ser estática, lo que significa que no debe contener valores que puedan cambiar con el tiempo. De lo contrario, aumentaría la cantidad de trabajo que se dedica a las operaciones de actualización y podría ralentizar el rendimiento.

Si bien la fragmentación basada en claves es una arquitectura de fragmentación bastante común, puede complicar las cosas cuando se intenta agregar o eliminar dinámicamente servidores adicionales a una base de datos. A medida que agrega servidores, cada uno necesitará un valor hash correspondiente y muchas de sus entradas existentes, si no todas, deberán reasignarse a su nuevo valor hash correcto y luego migrarse al servidor apropiado. A medida que comienza a reequilibrar los datos, ni las funciones hash nuevas ni las antiguas serán válidas. En consecuencia, su servidor no podrá escribir ningún dato nuevo durante la migración y su aplicación podría estar sujeta a tiempos de inactividad.

El principal atractivo de esta estrategia es que se puede utilizar para distribuir los datos de manera uniforme y evitar puntos conflictivos. Además, como distribuye los datos de forma algorítmica, no es necesario mantener un mapa de la ubicación de todos los datos, como es necesario con otras estrategias como la fragmentación basada en rangos o directorios.

Fragmentación basada en rangos

La fragmentación basada en rangos implica fragmentar los datos en función de rangos de un valor determinado. Para ilustrarlo, supongamos que tiene una base de datos que almacena información sobre todos los productos del catálogo de un minorista. Podría crear algunos fragmentos diferentes y dividir la información de cada producto en función del rango de precios en el que se encuentre, de la siguiente manera:

La principal ventaja de la fragmentación basada en rangos es que es relativamente sencilla de implementar. Cada fragmento contiene un conjunto de datos diferente, pero todos tienen un esquema idéntico entre sí, así como la base de datos original. El código de la aplicación lee en qué rango se encuentran los datos y los escribe en el fragmento correspondiente.

Por otro lado, la fragmentación basada en rangos no protege los datos de una distribución desigual, lo que genera los puntos críticos de la base de datos antes mencionados. Si observamos el diagrama de ejemplo, incluso si cada fragmento contiene la misma cantidad de datos, lo más probable es que determinados productos reciban más atención que otros. Sus respectivos fragmentos, a su vez, recibirán una cantidad desproporcionada de lecturas.

Fragmentación basada en directorios

Para implementar la fragmentación basada en directorios , se debe crear y mantener una tabla de búsqueda que utilice una clave de fragmento para realizar un seguimiento de qué fragmento contiene qué datos. Una tabla de búsqueda es una tabla que contiene un conjunto estático de información sobre dónde se pueden encontrar datos específicos. El siguiente diagrama muestra un ejemplo simplista de fragmentación basada en directorios:

Aquí, la columna de zona de entrega se define como una clave de fragmento. Los datos de la clave de fragmento se escriben en la tabla de búsqueda junto con el fragmento en el que se debe escribir cada fila respectiva. Esto es similar a la fragmentación basada en rango, pero en lugar de determinar en qué rango se encuentran los datos de la clave de fragmento, cada clave está vinculada a su propio fragmento específico. La fragmentación basada en directorio es una buena opción en lugar de la fragmentación basada en rango en los casos en que la clave de fragmento tiene una cardinalidad baja (es decir, tiene una cantidad baja de valores posibles) y no tiene sentido que un fragmento almacene un rango de claves. Tenga en cuenta que también se diferencia de la fragmentación basada en clave en que no procesa la clave de fragmento a través de una función hash; solo verifica la clave con una tabla de búsqueda para ver dónde se deben escribir los datos.

El principal atractivo de la fragmentación basada en directorios es su flexibilidad. Las arquitecturas de fragmentación basadas en rangos lo limitan a especificar rangos de valores, mientras que las basadas en claves lo limitan a usar una función hash fija que, como se mencionó anteriormente, puede ser extremadamente difícil de cambiar más adelante. La fragmentación basada en directorios, por otro lado, le permite usar cualquier sistema o algoritmo que desee para asignar entradas de datos a los fragmentos, y es relativamente fácil agregar fragmentos de manera dinámica utilizando este enfoque.

Si bien la fragmentación basada en directorios es el método de fragmentación más flexible de los que se analizan aquí, la necesidad de conectarse a la tabla de búsqueda antes de cada consulta o escritura puede tener un impacto negativo en el rendimiento de una aplicación. Además, la tabla de búsqueda puede convertirse en un único punto de falla: si se corrompe o falla de alguna otra manera, puede afectar la capacidad de escribir nuevos datos o acceder a los datos existentes.

¿Debería fragmentar?

La conveniencia o no de implementar una arquitectura de base de datos fragmentada es casi siempre un tema de debate. Algunos consideran que la fragmentación es un resultado inevitable para las bases de datos que alcanzan un cierto tamaño, mientras que otros la ven como un dolor de cabeza que se debe evitar a menos que sea absolutamente necesario, debido a la complejidad operativa que agrega la fragmentación.

Debido a esta complejidad adicional, la fragmentación generalmente solo se realiza cuando se trabaja con grandes cantidades de datos. A continuación, se muestran algunos escenarios comunes en los que puede resultar beneficioso fragmentar una base de datos:

• La cantidad de datos de la aplicación crece hasta superar la capacidad de almacenamiento de un solo nodo de base de datos.
• El volumen de escrituras o lecturas en la base de datos supera lo que un solo nodo o sus réplicas de lectura pueden manejar, lo que genera tiempos de respuesta más lentos o tiempos de espera agotados.
• El ancho de banda de red requerido por la aplicación supera el ancho de banda disponible para un solo nodo de base de datos y cualquier réplica de lectura, lo que genera tiempos de respuesta más lentos o tiempos de espera.

Antes de realizar la fragmentación, debe agotar todas las demás opciones para optimizar su base de datos. Algunas optimizaciones que puede considerar son:

• Configuración de una base de datos remota . Si trabaja con una aplicación monolítica en la que todos sus componentes residen en el mismo servidor, puede mejorar el rendimiento de su base de datos trasladándola a su propia máquina. Esto no agrega tanta complejidad como la fragmentación, ya que las tablas de la base de datos permanecen intactas. Sin embargo, aún le permite escalar verticalmente su base de datos independientemente del resto de su infraestructura.
• Implementación del almacenamiento en caché . Si el rendimiento de lectura de su aplicación es lo que le está causando problemas, el almacenamiento en caché es una estrategia que puede ayudar a mejorarlo. El almacenamiento en caché implica almacenar temporalmente datos que ya se han solicitado en la memoria, lo que le permite acceder a ellos mucho más rápido más adelante.
• Creación de una o más réplicas de lectura . Otra estrategia que puede ayudar a mejorar el rendimiento de lectura consiste en copiar los datos de un servidor de base de datos (el servidor principal ) a uno o más servidores secundarios . A continuación, cada nueva escritura se realiza en el servidor principal antes de copiarse en los secundarios, mientras que las lecturas se realizan exclusivamente en los servidores secundarios. Distribuir las lecturas y escrituras de esta manera evita que una sola máquina asuma demasiada carga, lo que ayuda a prevenir ralentizaciones y fallos. Tenga en cuenta que la creación de réplicas de lectura implica más recursos informáticos y, por tanto, cuesta más dinero, lo que podría ser una limitación importante para algunos.
• Actualización a un servidor más grande . En la mayoría de los casos, ampliar el servidor de base de datos a una máquina con más recursos requiere menos esfuerzo que la fragmentación. Al igual que con la creación de réplicas de lectura, un servidor actualizado con más recursos probablemente costará más dinero. En consecuencia, solo debe realizar el cambio de tamaño si realmente termina siendo su mejor opción.

Tenga en cuenta que si su aplicación o sitio web crece más allá de cierto punto, ninguna de estas estrategias será suficiente para mejorar el rendimiento por sí sola. En tales casos, la fragmentación puede ser la mejor opción para usted.

Conclusión

La fragmentación puede ser una gran solución para quienes buscan escalar su base de datos horizontalmente. Sin embargo, también agrega mucha complejidad y crea más puntos de falla potenciales para su aplicación. La fragmentación puede ser necesaria para algunos, pero el tiempo y los recursos necesarios para crear y mantener una arquitectura fragmentada podrían superar los beneficios para otros.

Al leer este artículo conceptual, debería tener una comprensión más clara de las ventajas y desventajas de la fragmentación. En el futuro, puede usar esta información para tomar una decisión más informada sobre si una arquitectura de base de datos fragmentada es adecuada o no para su aplicación.