Este artículo apareció por primera vez en InfoWorld . Se reproduce con autorización. © IDG Communications, Inc., 2020. Todos los derechos reservados Cómo MariaDB logra una escala global con Xpand. Xpand ahora está disponible en MariaDB SkySQL agregando SQL distribuido para escalabilidad y elasticidad en la nube.
A medida que crecieron las necesidades de información y procesamiento, los puntos débiles como el rendimiento y la resiliencia requirieron nuevas soluciones. Las bases de datos deben mantener el cumplimiento y la consistencia de ACID, proporcionar alta disponibilidad y alto rendimiento, y manejar cargas de trabajo masivas sin convertirse en una pérdida de recursos. La fragmentación ha ofrecido una solución, pero para muchas empresas la fragmentación ha llegado a sus límites, debido a su complejidad y requisitos de recursos. Una mejor solución es SQL distribuido.
En una implementación SQL distribuida, la base de datos se distribuye a través de múltiples sistemas físicos, entregando transacciones a un nivel escalable globalmente. MariaDB Platform X5, una versión importante que incluye actualizaciones de todos los aspectos de MariaDB Platform, proporciona SQL distribuido y escalabilidad masiva mediante la adición de un nuevo motor de almacenamiento inteligente llamado Xpand. Con una arquitectura de nada compartido, transacciones ACID completamente distribuidas y una gran consistencia, Xpand le permite escalar a millones de transacciones por segundo.
Motores inteligentes enchufables optimizados
MariaDB Enterprise Server está diseñado para usar motores de almacenamiento conectables (como Xpand) para optimizar cargas de trabajo particulares desde una única plataforma. No hay necesidad de bases de datos especializadas para manejar cargas de trabajo específicas. MariaDB Xpand, nuestro motor inteligente para SQL distribuido, es la incorporación más reciente a nuestra línea. Xpand agrega capacidades transaccionales distribuidas masivamente escalables a las opciones proporcionadas por nuestros otros motores. Nuestros otros motores conectables brindan optimización para cargas de trabajo analíticas (en columnas), de lectura y escritura. Puede mezclar y combinar tablas replicadas, distribuidas y en columnas para optimizar cada base de datos para sus requisitos específicos.
La adición de MariaDB Xpand permite a los clientes empresariales obtener todos los beneficios de SQL distribuido (velocidad, disponibilidad y escalabilidad) al mismo tiempo que conservan los beneficios de MariaDB a los que están acostumbrados.
Echemos un vistazo de alto nivel a cómo MariaDB Xpand proporciona SQL distribuido.
SQL distribuido hasta los índices
Xpand proporciona SQL distribuido al dividir, replicar y distribuir datos entre nodos. ¿Qué significa esto? Usaremos un ejemplo muy simple con una tabla y tres nodos para demostrar los conceptos. No se muestra en este ejemplo que todos los sectores se replican.
En la Figura 1 anterior, tenemos una tabla con dos índices. La tabla tiene algunas fechas y tenemos un índice en la Columna Dos y otro en las Columnas Tres y Uno. Los índices son, en cierto sentido, tablas en sí mismos. Son subconjuntos de la tabla. La clave principal es id , el primer índice de la tabla. Eso es lo que se usará para codificar y distribuir los datos de la tabla en la base de datos.
Ahora añadimos la noción de rebanadas . Las rebanadas son esencialmente particiones horizontales de la tabla. Tenemos cinco filas en nuestra tabla. En la Figura 2, la tabla ha sido cortada y distribuida. El nodo #1 tiene dos filas. El nodo #2 tiene dos filas y el nodo #3 tiene una fila. El objetivo es tener los datos distribuidos de la manera más uniforme posible entre los nodos.
Los índices también han sido cortados y distribuidos. Esta es una diferencia clave entre Xpand y otras soluciones distribuidas. Por lo general, las bases de datos distribuidas tienen índices locales, por lo que cada nodo tiene un índice de sus propios datos. En Xpand, los índices se distribuyen y almacenan independientemente de la tabla. Esto elimina la necesidad de enviar una consulta a todos los nodos (dispersión/recopilación). En el ejemplo anterior, el nodo n.º 1 contiene las filas 2 y 4 de la tabla y también contiene índices para las filas 32 y 35 y las filas abril y marzo. La tabla y los índices se dividen, distribuyen y replican de forma independiente en los nodos.
El motor de consulta utiliza los índices distribuidos para determinar dónde encontrar los datos. Busca solo las particiones de índice necesarias y luego envía consultas solo a las ubicaciones donde residen los datos necesarios. Las consultas están todas distribuidas. Se realizan simultáneamente y en paralelo. Adónde van depende completamente de los datos y de lo que se necesita para resolver la consulta.
Todos los cortes se replican al menos dos veces. Para cada segmento, hay réplicas que residen en otros nodos. De manera predeterminada, habrá tres copias de esos datos:el segmento y dos réplicas. Cada copia estará en un nodo diferente, y si estuviera ejecutando en varias zonas de disponibilidad, esas copias también estarían en diferentes zonas de disponibilidad.
Manejo de lectura y escritura
Tomemos otro ejemplo. En la Figura 3, tenemos cinco instancias de MariaDB Enterprise Server con Xpand (nodos). Hay una tabla para almacenar perfiles de clientes. El segmento con el perfil de Shane está en el nodo n.° 1 con copias en el nodo n.° 3 y el nodo n.° 5. Las consultas pueden ingresar en cualquier nodo y se procesarán de manera diferente dependiendo de si son de lectura o escritura.
Las escrituras se realizan en todas las copias de forma síncrona dentro de una transacción distribuida. Cada vez que actualizo mi perfil de "Shane" porque cambié mi correo electrónico o cambié mi dirección, esos escritos van a todas las copias al mismo tiempo dentro de una transacción. Esto es lo que proporciona una fuerte consistencia.
En la Figura 3, la declaración UPDATE fue al Nodo #2. No hay nada en el Nodo n.° 2 con respecto a mi perfil, pero el Nodo n.° 2 sabe dónde está mi perfil y envía actualizaciones al Nodo n.° 1, Nodo n.° 3 y Nodo n.° 5, luego confirma esa transacción y regresa a la aplicación.
Las lecturas se manejan de manera diferente. En el diagrama, el corte con mi perfil está en el Nodo n.º 1 con copias en el Nodo n.º 3 y el Nodo n.º 5. Esto convierte al Nodo #1 en la réplica de clasificación. Cada segmento tiene una réplica de clasificación, que podría decirse que es el nodo que "posee" los datos. De manera predeterminada, sin importar en qué nodo ingrese una lectura, siempre va a la réplica de clasificación, por lo que cada SELECT que me resuelva irá al Nodo #1.
Aportando elasticidad
Las bases de datos distribuidas como Xpand cambian y evolucionan continuamente según los datos de la aplicación. El proceso de rebalanceo es responsable de adaptar la distribución de datos a las necesidades actuales y de mantener la distribución óptima de los segmentos entre los nodos. Hay tres escenarios generales que requieren redistribución:agregar nodos, eliminar nodos y evitar cargas de trabajo desiguales o "puntos conflictivos".
Por ejemplo, supongamos que estamos ejecutando con tres nodos pero encontramos que el tráfico está aumentando y necesitamos escalar:agregamos un cuarto nodo para manejar el tráfico. El nodo n.° 4 está vacío cuando lo agregamos, como se muestra en la figura 4. El reequilibrador mueve automáticamente los sectores y las réplicas para utilizar el nodo n.° 4, como se muestra en la figura 5.
Si el Nodo #4 falla, el rebalanceador vuelve a funcionar automáticamente; esta vez recreando rebanadas de sus réplicas. No se pierde ningún dato. Las réplicas también se recrean para reemplazar las que residían en el nodo n.° 4, por lo que todos los segmentos nuevamente tienen réplicas en otros nodos para garantizar una alta disponibilidad.
Figura 6. Si falla un nodo, el reequilibrador Xpand recrea los segmentos y las réplicas que residían en el nodo fallido a partir de los datos de réplica en los otros nodos.
Equilibrar la carga de trabajo
Además de la escalabilidad horizontal y la alta disponibilidad, el reequilibrador mitiga la distribución desigual de la carga de trabajo, ya sea puntos calientes o infrautilización. Incluso cuando los datos se distribuyen aleatoriamente con un algoritmo hash perfecto, pueden ocurrir puntos calientes. Por ejemplo, podría suceder por casualidad que los 10 productos a la venta este mes se encuentren en el Nodo #1. Los datos se distribuyen uniformemente, pero la carga de trabajo no (Figura 7). En este tipo de escenario, el reequilibrador redistribuirá segmentos para equilibrar la utilización de recursos (Figura 8).
Figura 7. Xpand ha distribuido uniformemente los datos pero la carga de trabajo es desigual. El nodo 1 tiene una carga de trabajo significativamente mayor que los otros tres nodos.
Figura 8. El reequilibrador Xpand redistribuye segmentos de datos para equilibrar la carga de trabajo entre los nodos.
Escalabilidad, velocidad, disponibilidad, equilibrio
Las necesidades de información y procesamiento seguirán creciendo. Eso es un hecho. MariaDB Xpand proporciona una solución de escalado coherente y compatible con ACID para empresas con requisitos que no se pueden cumplir con otras alternativas como la replicación y la fragmentación.
SQL distribuido proporciona escalabilidad y MariaDB Xpand proporciona la flexibilidad para elegir cuánta escalabilidad necesita. Distribuya una tabla o varias tablas o incluso toda su base de datos, la elección es suya. Desde el punto de vista operativo, la capacidad se ajusta fácilmente para satisfacer las cambiantes demandas de carga de trabajo en un momento dado. Nunca tendrá que aprovisionarse en exceso.
Xpand también protege de manera transparente contra la utilización desigual de recursos, redistribuyendo datos dinámicamente para equilibrar la carga de trabajo entre los nodos y evitar puntos calientes. Para los desarrolladores, no hay necesidad de preocuparse por la escalabilidad y el rendimiento. Xpand es elástico. Xpand también proporciona redundancia y alta disponibilidad. Con datos divididos, replicados y distribuidos entre nodos, los datos están protegidos y se mantiene la redundancia en caso de falla del hardware.
Y, con la arquitectura de MariaDB, sus tablas distribuidas funcionarán bien, incluidas las JOIN entre motores, con sus otras tablas de MariaDB. Cree la solución de base de datos que necesita mezclando y combinando tablas replicadas, distribuidas o en columnas, todo en una sola base de datos en la plataforma MariaDB.
