El diseño de sistemas es una de las rondas de entrevistas más importantes para los ingenieros de software en las grandes empresas tecnológicas. Hay muchos conceptos que un ingeniero debe tener en cuenta y la fragmentación de la base de datos es uno de ellos. Cada vez que una aplicación comienza a recibir una gran cantidad de requests simultáneas y ve un crecimiento significativo de los usuarios en el sitio web, eventualmente necesita escalar para manejar la cantidad creciente de datos o tráfico en el sitio web. Es difícil predecir el crecimiento del sitio web en el futuro y no podemos predecir cuánto tiempo un sitio web mantendrá su popularidad y crecimiento. Entonces, necesitamos escalar nuestra base de datos dinámicamente y la fragmentación de la base de datos es la técnica que puede cumplir con este trabajo. Entendamos este concepto en detalle.
¿Qué es Sharding o partición de datos?
Tome el ejemplo de la pizza ( sí, su comida favorita ). Obtienes la pizza en diferentes porciones y compartes estas porciones con tus amigos. La fragmentación, que también se conoce como partición de datos , funciona con el mismo concepto de compartir las porciones de pizza. Es básicamente un patrón de arquitectura de base de datos en el que dividimos un gran conjunto de datos en fragmentos más pequeños (fragmentos lógicos) y almacenamos/distribuimos estos fragmentos en diferentes máquinas/Nodes de base de datos (fragmentos físicos). Cada fragmento/partición se conoce como » fragmento » y cada fragmento tiene el mismo esquema de base de datos que la base de datos original. Distribuimos los datos de tal manera que cada fila aparece exactamente en un fragmento. Es un buen mecanismo para mejorar la escalabilidad .de una aplicación
Los fragmentos de base de datos son autónomos; no comparten ninguno de los mismos datos o recursos informáticos. Sin embargo, en algunos casos, puede tener sentido replicar ciertas tablas en cada fragmento para que sirvan como tablas de referencia.
Ventajas de la fragmentación
- Resuelva el problema de escalabilidad: con una arquitectura de servidor de base de datos única, cualquier aplicación experimenta una degradación del rendimiento cuando los usuarios comienzan a crecer en esa aplicación. Las consultas de lectura y escritura se vuelven más lentas y el ancho de banda de la red comienza a saturarse. En algún momento, se quedará sin espacio en disco. La fragmentación de la base de datos soluciona todos estos problemas al dividir los datos en varias máquinas.
- Alta disponibilidad: un problema con la arquitectura de un solo servidor es que si ocurre una interrupción, toda la aplicación no estará disponible, lo que no es bueno para un sitio web con más usuarios. Este no es el caso con una base de datos fragmentada. Si ocurre una interrupción en la arquitectura fragmentada, solo algunos fragmentos específicos estarán inactivos. Todos los demás fragmentos continuarán con la operación y la aplicación completa no dejará de estar disponible para los usuarios.
- Acelere el tiempo de respuesta de la consulta: cuando envía una consulta en una aplicación con una gran base de datos monolítica y no tiene una arquitectura fragmentada, lleva más tiempo encontrar el resultado. Tiene que buscar en cada fila de la tabla y eso ralentiza el tiempo de respuesta para la consulta que ha realizado. Esto no sucede en la arquitectura fragmentada. En una base de datos fragmentada, una consulta tiene que pasar por menos filas y recibe la respuesta en menos tiempo.
- Más ancho de banda de escritura: para muchas aplicaciones, la escritura es un cuello de botella importante. Sin una base de datos maestra que serialice escrituras, la arquitectura fragmentada le permite escribir en paralelo y aumentar su rendimiento de escritura.
- Escalamiento horizontal : fragmentar una base de datos facilita el escalamiento horizontal , conocido como escalamiento horizontal . En el escalado horizontal, agrega más máquinas en la red y distribuye la carga en estas máquinas para un procesamiento y una respuesta más rápidos. Esto tiene muchas ventajas. Puede hacer más trabajo simultáneamente y puede manejar muchas requests de los usuarios, especialmente al escribir datos porque hay rutas paralelas a través de su sistema. También puede equilibrar la carga de servidores web que acceden a fragmentos a través de diferentes rutas de red, que son procesados por diferentes CPU, y usar cachés separados de RAM o rutas de E/S de disco para procesar el trabajo.
Desventajas de la fragmentación
- Agrega complejidad en el sistema: debe tener cuidado al implementar una arquitectura de base de datos fragmentada adecuada en una aplicación. Es una tarea complicada y si no se implementa correctamente, puede perder los datos o dañar las tablas de su base de datos. También debe administrar los datos desde varias ubicaciones de fragmentos en lugar de administrarlos y acceder a ellos desde un único punto de entrada. Esto puede afectar el flujo de trabajo de su equipo, lo que puede ser perjudicial para algunos equipos.
- Reequilibrio de datos: en una arquitectura de base de datos fragmentada, a veces los fragmentos se desequilibran (cuando un fragmento supera a otros fragmentos). Considere un ejemplo en el que tiene dos fragmentos de una base de datos. En un almacén de fragmentos, el nombre de los clientes comienza con las letras de la A a la M. En otro almacén de fragmentos, el nombre del cliente comienza con las letras de la N a la Z. Si hay tantos usuarios con la letra L, entonces el fragmento uno tendrá más datos que el fragmento. dos. Esto afectará el rendimiento (ralentización) de la aplicación y se detendrá para una parte significativa de sus usuarios. El fragmento AM se desequilibrará y se conocerá como punto de acceso de la base de datos. Para superar este problema y reequilibrar los datos, debe volver a fragmentar para lograr una distribución uniforme de los datos. Mover datos de un fragmento a otro fragmento no es una buena idea porque requiere muchos tiempos de inactividad.
- Unir datos de múltiples fragmentos es costoso: en una sola base de datos, las uniones se pueden realizar fácilmente para implementar cualquier funcionalidad. Pero en la arquitectura fragmentada, debe extraer los datos de diferentes fragmentos y debe realizar uniones en varios servidores en red. No puede enviar una sola consulta para obtener los datos de varios fragmentos. Debe enviar varias consultas para cada uno de los fragmentos, extraer los datos y unirlos en toda la red. Este va a ser un proceso muy costoso y lento. Agrega latencia a su sistema.
- Sin compatibilidad nativa: la fragmentación no es compatible de forma nativa con todos los motores de bases de datos. Por ejemplo, PostgreSQL no incluye funciones de fragmentación automática, por lo que debe realizar una fragmentación manual. Debe seguir el enfoque de «roll-your-own». Será difícil para usted encontrar los consejos o la documentación para la fragmentación y solucionar el problema durante la implementación de la fragmentación.
Arquitecturas fragmentadas
1. Fragmentación basada en claves
Esta técnica también se conoce como fragmentación basada en hash. Aquí, tomamos el valor de una entidad como la identificación del cliente, el correo electrónico del cliente, la dirección IP de un cliente, el código postal, etc. y usamos este valor como entrada de la función hash . Este proceso genera un valor hash que se usa para determinar qué fragmento necesitamos usar para almacenar los datos. Debemos tener en cuenta que los valores ingresados en la función hash deben provenir todos de la misma columna (clave de fragmento) solo para garantizar que los datos se coloquen en el orden correcto y de manera consistente. Básicamente, las claves de fragmento actúan como una clave principal o un identificador único para filas individuales.
Considere un ejemplo en el que tiene 3 servidores de base de datos y cada solicitud tiene una identificación de aplicación que se incrementa en 1 cada vez que se registra una nueva aplicación. Para determinar en qué servidor se deben colocar los datos, realizamos una operación de módulo en la identificación de estas aplicaciones con el número 3. Luego, el resto se usa para identificar el servidor para almacenar nuestros datos.
La desventaja de este método es el equilibrio de carga elástico, lo que significa que si intenta agregar o eliminar los servidores de la base de datos dinámicamente, será un proceso difícil y costoso. Por ejemplo, en el anterior, si agregará 5 servidores más, entonces necesita agregar más valores hash correspondientes para las entradas adicionales. Además, la mayoría de las claves existentes deben reasignarse a su nuevo valor hash correcto y luego migrarse a un nuevo servidor. La función hash debe cambiarse del módulo 3 al módulo 8. Mientras la migración de datos esté en vigor, las funciones hash nuevas y antiguas no serán válidas. Durante la migración, su aplicación no podrá atender una gran cantidad de requests y experimentará un tiempo de inactividad para su aplicación hasta que se complete la migración.
Nota: un fragmento no debe contener valores que puedan cambiar con el tiempo. Debe ser siempre estático, de lo contrario ralentizará el rendimiento.
2. Fragmentación horizontal o basada en rango
En este método, dividimos los datos en función de los rangos de un valor dado inherente a cada entidad. Supongamos que tiene una base de datos de los nombres y la información de correo electrónico de sus clientes en línea. Puede dividir esta información en dos fragmentos. En un fragmento puede guardar la información de los clientes cuyo primer nombre comienza con AP y en otro fragmento, guardar la información del resto de los clientes.
La fragmentación basada en rangos es el método de fragmentación más simple de implementar. Cada fragmento contiene un conjunto diferente de datos, pero todos tienen el mismo esquema que la base de datos original. En este método, solo necesita identificar en qué rango se encuentran sus datos y luego puede almacenar la entrada en el fragmento correspondiente. Este método es el más adecuado para almacenar datos no estáticos (ejemplo: almacenar la información de contacto de los estudiantes en una universidad).
El inconveniente de este método es que es posible que los datos no se distribuyan uniformemente en fragmentos. En el ejemplo anterior, es posible que tenga muchos clientes cuyos nombres pertenecen a la categoría de AP. En tales casos, el primer fragmento tendrá que soportar más carga que el segundo y puede convertirse en un cuello de botella del sistema.
3. Fragmentación vertical
En este método, separamos toda la columna de la tabla y colocamos esas columnas en nuevas tablas distintas. Los datos son totalmente independientes de una partición a las otras. Además, cada partición contiene filas y columnas distintas. Tomemos el ejemplo de las características de Twitter. Podemos dividir diferentes características de una entidad en diferentes fragmentos en diferentes máquinas. En Twitter, los usuarios pueden tener un perfil, número de seguidores y algunos tweets publicados por ellos mismos. Podemos colocar los perfiles de usuario en un fragmento, los seguidores en el segundo fragmento y los tweets en un tercer fragmento.
En este método, puede separar y manejar la parte crítica (por ejemplo, perfiles de usuario) y la parte no crítica de sus datos (por ejemplo, publicaciones de blog) individualmente y construir diferentes modelos de replicación y consistencia a su alrededor. Esta es una de las principales ventajas de este método.
El principal inconveniente de este esquema es que, para responder a algunas consultas, es posible que deba combinar los datos de diferentes fragmentos, lo que aumenta innecesariamente la complejidad operativa y de desarrollo del sistema. Además, si su aplicación crecerá más tarde y agrega algunas funciones más, tendrá que fragmentar aún más una base de datos específica de funciones en varios servidores.
4. Fragmentación basada en directorios
En este método, creamos y mantenemos un servicio de búsqueda o una tabla de búsqueda para la base de datos original. Básicamente, usamos una clave de fragmento para la tabla de búsqueda y hacemos un mapeo para cada entidad que existe en la base de datos. De esta manera, hacemos un seguimiento de qué fragmentos de base de datos contienen qué datos.
La tabla de búsqueda contiene un conjunto estático de información sobre dónde se pueden encontrar datos específicos. En la imagen de arriba, puede ver que hemos utilizado la zona de entrega como clave de fragmento. En primer lugar, la aplicación cliente consulta el servicio de búsqueda para averiguar el fragmento (partición de la base de datos) en el que se colocan los datos. Cuando el servicio de búsqueda devuelve el fragmento, consulta/actualiza ese fragmento.
La fragmentación basada en directorios es mucho más flexible que la fragmentación basada en rangos y claves. En la fragmentación basada en rangos, está obligado a especificar los rangos de valores. En el modo basado en claves, está obligado a utilizar una función hash fija que es difícil de cambiar más adelante. En este enfoque, puede usar cualquier algoritmo que desee asignar a las entradas de datos de los fragmentos. Además, es fácil agregar fragmentos dinámicamente en este enfoque.
El principal inconveniente de este enfoque es el único punto de falla de la tabla de búsqueda. Si se corrompe o falla, afectará la escritura de nuevos datos o el acceso a los datos existentes de la tabla.
Conclusión
Sharding es una gran solución cuando la base de datos única de su aplicación no es capaz de manejar/almacenar una gran cantidad de datos en crecimiento. La fragmentación ayuda a escalar la base de datos y mejorar el rendimiento de la aplicación. Sin embargo, también agrega cierta complejidad a su sistema. Los métodos y arquitecturas anteriores han mostrado claramente las ventajas y desventajas de cada técnica de fragmentación. Entonces, antes de decidir elegir cualquier método de fragmentación, asegúrese de comparar cada uno de ellos y, según el tipo de información almacenada en la base de datos, elija fragmentación o cualquiera de las técnicas de fragmentación.
Lea más sobre el diseño del sistema en el enlace ¿Cómo descifrar la ronda de diseño del sistema en las entrevistas?
Publicación traducida automáticamente
Artículo escrito por anuupadhyay y traducido por Barcelona Geeks. The original can be accessed here. Licence: CCBY-SA