Código fuente de MySQLproxy
Por lo tanto, en el proceso de expansión empresarial, las aplicaciones han planteado mayores requisitos para la robustez, seguridad y escalabilidad del sistema de base de datos.
Ahora, te dejaré comenzar con la arquitectura, selección e implementación de la base de datos.
¿Qué desafíos enfrentará la base de datos?
En los primeros días de nuestro negocio, solo usábamos una base de datos de una sola máquina. Sin embargo, a medida que el negocio crece, la escala de datos y la escala de usuarios aumentan. En este momento, la base de datos enfrentará cuellos de botella de IO, cuellos de botella de almacenamiento, disponibilidad y problemas de seguridad.
Para resolver los problemas anteriores, se derivan diferentes arquitecturas de la base de datos para resolver las necesidades de diferentes escenarios.
Las operaciones de escritura y lectura de la base de datos están separadas. La biblioteca maestra recibe solicitudes de escritura y se utilizan varias copias de la biblioteca esclava para procesar las solicitudes de lectura. La base de datos esclava y la base de datos maestra actualizan los datos sincrónicamente para mantener la coherencia de los datos, y la base de datos esclava puede escalar horizontalmente para hacer frente al aumento de solicitudes de lectura.
Este modo también se llama separación de lectura y escritura. Está dirigido a datos de pequeña escala y tiene una gran cantidad de operaciones de lectura.
Debido a que los datos maestro-esclavo son los mismos, una vez que la base de datos maestra deja de funcionar, la base de datos esclava puede cambiar a la base de datos maestra para proporcionar escritura, por lo que esta arquitectura también puede mejorar la seguridad y disponibilidad de la base de datos. system;
Ventajas:
Desventajas:
Cuando la base de datos encuentra un cuello de botella de IO, si el IO se concentra en un determinado negocio, puede considerar mover el hot business Divídalo verticalmente para evitar que otras empresas normales se vean afectadas por solicitudes intensivas de E/S de hot business, por lo que las ramas verticales también se denominan ramas comerciales.
Ventajas:
Desventajas:
Cuando la base de datos encuentra un cuello de botella de almacenamiento, el rendimiento del índice disminuirá debido al volumen excesivo de datos.
En este momento, puede considerar dividir los datos horizontalmente y dividir una sola tabla con una gran cantidad de datos en varias tablas de acuerdo con ciertas reglas.
Pero estas tablas todavía están en la misma biblioteca, por lo que todavía hay un cuello de botella de IO en las operaciones de bases de datos a nivel de biblioteca (la IO de un solo servidor tiene un límite superior).
Por lo tanto, las subtablas horizontales están dirigidas principalmente a escenarios con grandes cantidades de datos y bajas solicitudes comerciales generales.
Ventajas:
Desventajas:
Cuarto, subbiblioteca y subtabla
Cuando la base de datos encuentra cuellos de botella de almacenamiento y cuellos de botella de IO El rendimiento del índice disminuirá debido a la gran cantidad de datos y la necesidad de manejar solicitudes comerciales a gran escala. En este momento, el límite superior de IO de una única base de datos limitará la eficiencia del procesamiento.
Por lo tanto, los datos de una sola tabla deben dividirse en varios servidores. Cada servidor tiene una biblioteca y una tabla correspondientes, pero los conjuntos de datos de la tabla son diferentes.
Las subbases de datos y las subtablas pueden aliviar eficazmente los cuellos de botella en el rendimiento y la presión de una sola máquina y una sola base de datos, y superar los cuellos de botella de IO, la cantidad de conexiones y los recursos de hardware.
Ventajas:
Desventajas:
Nota: si hay un cuello de botella de IO es la clave para la subbase de datos o la subtabla.
¿Cuáles son los métodos de fragmentación?
Rango (división de rango)
Después de ordenar un campo clave en la tabla de negocios, habrá una tabla de 0 a 10000 y una tabla de 10001 a 20000. La más común es la división del tiempo (tabla mensual, tabla cronológica).
Por ejemplo, recorte los datos de hace medio año o incluso un año y colóquelos en otra tabla, porque a medida que pasa el tiempo, la probabilidad de que aparezcan los datos en estas tablas se vuelve menor y la mayoría registros de transacciones bancarias Eso es todo.
Ventajas:
Desventajas:
Hash (porción hash)
Usar pedidos como tabla principal y luego su relación El negocio table es una tabla adjunta, que toma el ID de usuario y luego codifica el módulo para distribuirlo a diferentes tablas de datos o bases de datos.
Ventajas:
Desventajas:
A estas alturas ya sabemos qué tipo de arquitectura tiene la base de datos y qué problemas soluciona. Por tanto, en el diseño diario, debemos elegir diferentes arquitecturas en función de las características, tendencias y seguridad de los datos.
Entonces, ¿cómo debemos elegir la arquitectura de la base de datos?
Aunque todas las arquitecturas anteriores se pueden combinar para formar un potente sistema de base de datos de alta disponibilidad y alta carga, lo más importante es elegir la arquitectura adecuada.
Aunque la arquitectura híbrida puede resolver todos los problemas del escenario, también enfrentará más desafíos. Lo que usted cree que es un edificio perfecto en realidad tiene más trampas detrás.
1. Soporte de transacciones
Después de dividir la base de datos en tablas (ya sea vertical u horizontalmente), se convierte en una transacción distribuida. Si confiamos en la función de gestión de transacciones distribuidas de la propia base de datos para ejecutar transacciones, pagaremos un alto precio de rendimiento (transacciones XA, si utilizamos el control asistido por aplicaciones, provocará una carga de programación (TCC, SAGA);
2. La base de agrupación (base de clasificación) de los resultados de múltiples bases de datos.
Dado que los datos se distribuyen en diferentes bases de datos, la paginación, agrupación, clasificación y otras operaciones no se pueden realizar directamente. En términos generales, se utilizan otros métodos (TIDB, bibliotecas, etc.) para manejar el negocio de consultas de agregación de resultados de múltiples bases de datos.
3. Retraso de datos
Ya sea un mecanismo de copia múltiple bajo una arquitectura maestro-esclavo o una biblioteca de agregación después de la separación horizontal de la biblioteca, habrá un problema de retraso entre los datos maestros. y datos de réplica.
4. Conexión entre bases de datos
Después de dividir la subbase de datos y la subtabla, las operaciones de asociación entre tablas estarán restringidas. No podemos unir tablas ubicadas en diferentes subbases de datos (verticales) ni unir tablas de diferentes granularidades (horizontales). Por lo tanto, un negocio que se puede completar con una consulta puede requerir varias consultas.
5. Expansión del segmento
Después del corte horizontal, es necesario expandirlo una vez. Los datos correspondientes deben migrarse una vez, lo que resulta extremadamente costoso.
6. Generación de ID
Debido a la independencia de la base de datos, la ID de aumento automático basada en la base de datos ya no se puede utilizar. En este momento, es necesario adoptar otros esquemas de generación de identificación externa.
Primero, la clase de dependencia de la capa de aplicación (JDBC)
Este tipo de middleware se caracteriza por un fuerte acoplamiento con la aplicación, y la visualización de la aplicación debe depender del paquete jar correspondiente (tomando Java como ejemplo), como el conocido TDDL, Dangdang open source sharding-jdbc, TSharding de Mogujie, etc.
La idea básica de este tipo de middleware es volver a implementar la API JDBC. . Al reimplementar las interfaces para operar bases de datos como DataSource y PrepareStatement, la capa de aplicación puede realizar de manera transparente la capacidad de dividir bases de datos y tablas sin cambiar básicamente el código comercial.
El middleware proporciona una API JDBC familiar para aplicaciones de capa superior. A través de una serie de preparativos como análisis de SQL, reescritura de SQL, enrutamiento de SQL, etc., obtiene SQL verdaderamente ejecutable internamente y luego la parte inferior. La capa utiliza métodos tradicionales (como el grupo de conexiones de bases de datos), obtiene una conexión física para ejecutar SQL y finalmente fusiona los resultados de los datos en un ResultSet y lo devuelve a la capa de aplicación.
Ventajas
Desventajas
2. Clase de proxy de capa intermedia (Proxy)
El principio básico de este tipo de middleware es establecer una capa de proxy entre la base de datos y la base de datos. La aplicación de la capa superior utiliza el protocolo MySQL estándar para conectarse a la capa proxy, y luego la capa proxy es responsable de reenviar la solicitud a la instancia física de MySQL de la capa inferior. Este enfoque solo requiere que las aplicaciones se comuniquen mediante el protocolo MySQL.
Por lo tanto, un cliente puro como MySQL Navicat puede conectarse directamente a su base de datos distribuida y, naturalmente, admite todos los lenguajes de programación.
En términos de implementación técnica, es básicamente similar a la capa de aplicación que depende del middleware. Los productos de subbase de datos y subtabla de la clase proxy deben implementar el protocolo MySQL estándar. En cierto sentido, la capa de proxy de la base de datos reenvía solicitudes del protocolo MySQL al igual que Nginx reenvía solicitudes del protocolo HTTP.
Los productos representativos incluyen el pionero Amoeba, el código abierto Cobar de Alibaba y el Mycat desarrollado por la comunidad (basado en Cobar).
Ventajas
Desventajas
Solución JDBC: arquitectura no centralizada, compatible con la mayoría de bases de datos relacionales del mercado, adecuada para desarrollar aplicaciones OLTP ligeras de alto rendimiento ( para recepción).
Solución de agente: Proporciona portal estático y soporte de lenguajes heterogéneos, adecuado para aplicaciones OLAP (orientadas a backend) y escenarios para administrar y operar bases de datos fragmentadas.
Solución híbrida: en sistemas grandes y complejos, existen aplicaciones front-end para usuarios del lado C y aplicaciones back-end para análisis empresarial. En este caso, se puede adoptar un modelo híbrido.
JDBC adopta una arquitectura distribuida y es adecuado para aplicaciones OLTP ligeras de alto rendimiento desarrolladas en Java. El agente proporciona portal estático y soporte de lenguaje heterogéneo y es adecuado para aplicaciones y escenarios OLAP para administrar y operar bases de datos fragmentadas.
ShardingSphere es un ecosistema de soluciones middleware de bases de datos distribuidas de código abierto, que consta de tres productos independientes, Sharding-JDBC, Sharding-Proxy y Sharding-Sidecar (planificado). Todos proporcionan fragmentación de datos estandarizada, transacciones distribuidas y funciones de administración de bases de datos, y se pueden aplicar a una variedad de escenarios de aplicaciones como isomorfismo de Java, lenguajes heterogéneos, contenedores y nativos de la nube.
Funciones principales proporcionadas por ShardingSphere:
Agente de fragmentación
Posicionado como un agente de base de datos transparente, proporciona una versión de servidor que encapsula el protocolo binario de la base de datos para admitir heterogeneidad. idiomas.
Actualmente, se ha proporcionado una versión de MySQL. Puede utilizar cualquier cliente de acceso compatible con el protocolo MySQL (como el cliente de comandos MySQL, MySQL Workbench, Navicat, etc.) para operar los datos, lo cual es más amigable. a los DBA.
Completamente transparente para la aplicación y se puede utilizar directamente como MySQL.
Aplicable a cualquier cliente compatible con el protocolo MySQL.
Sardin-JDBC
Posicionado como un mvc de resorte liviano, proporciona servicios adicionales en la capa JDBC de Java. Utiliza el cliente para conectarse directamente a la base de datos y proporciona servicios en forma de paquetes jar sin requerir implementación ni dependencias adicionales. Puede entenderse como un controlador JDBC mejorado, totalmente compatible con JDBC y varios marcos ORM.
Tome el sistema SaaS de comercio electrónico como ejemplo. La aplicación front-end utiliza sharding-JDBC, que se divide principalmente en tres soluciones según diferentes escenarios comerciales.
Subbase de datos (usuario)
Análisis del problema: la empresa principal tiene una alta actividad diaria y una alta concurrencia, y la base de datos se divide por separado para evitar molestar a otros usuarios de la empresa. Los datos del usuario crecen lentamente y se pueden dividir en tablas.
Dimensión dividida: biblioteca sucursal de Enterprise ID
Estrategia dividida: biblioteca independiente para empresas principales, una biblioteca para empresas no principales.
Subalmacén y subtabla (pedido)
Análisis del problema: los datos de pedidos están creciendo rápidamente y, además de la biblioteca, también necesitan subtablas.
División de dimensiones: subbase de ID de empresa y subtabla de ID de usuario.
Estrategia dividida: las empresas matrices tienen bibliotecas separadas y las empresas no matrices tienen bibliotecas. Una vez dividida la biblioteca, el ID de usuario se encuentra en la tabla de división del módulo.
Subtabla de base de datos única (adjunto)
Análisis del problema: los datos adjuntos se caracterizan por una pequeña concurrencia y solo necesitan resolver el problema del crecimiento de los datos, por lo que si una sola base de datos IO Si puede soportarlo lo suficiente, puede ser una subtabla.
Dimensión de división: subtabla de ID de usuario
Estrategia de división: tabla modular de ID de usuario.
Pregunta 1: Transacciones distribuidas
La complejidad de las transacciones distribuidas es también el problema más difícil de abordar en los sistemas distribuidos. Debido al espacio limitado, las siguientes reuniones se centrarán en esta parte.
Pregunta 2: ID distribuido
Pregunta 3: Consulta entre fragmentos
Por ejemplo, después de dividir por ID de usuario, debe consultar a todos los usuarios del empresa en función de la información de ID de empresa.
Harding también puede admitir consultas entre fragmentos. Básicamente, la consulta entre sectores de Harding consulta datos de varios sectores al mismo tiempo y luego agrega los resultados. Este método consume muchos recursos, especialmente la conexión a la base de datos.
Suponiendo que hay 4 bases de datos y 8 tablas, la fragmentación enviará 32 SQL para consulta al mismo tiempo. Consume 32 conexiones a la vez;
Especialmente para el caso en el que una única base de datos se divide en tablas, cabe señalar que si una única base de datos se divide en 64 tablas, se consumirán 64 conexiones. Si implementamos dos nodos, si ambos nodos consultan al mismo tiempo, encontraremos el problema del límite superior del número de conexiones de la base de datos (mysql por defecto es 100 conexiones).
Pregunta 4: Expansión segmentada
A medida que los datos crecen, los datos de cada región también alcanzarán cuellos de botella. En este momento, es necesario aumentar el número original de cortes.
Debido al aumento del área, las reglas de hash originales también han cambiado, lo que resulta en la necesidad de migrar datos antiguos.
Supongamos que los 100 millones de datos originales se han dividido en 64 tablas y ahora los 5 mil millones de datos deben ampliarse a 128 tablas. Una vez que se amplíe la capacidad, será necesario migrar 5 mil millones de datos una vez y el costo de la migración es inimaginable.
Pregunta 5: Hash consistente
Primero encuentre el valor hash de cada servidor y configúrelo en el anillo de 0 ~ 2 n (n generalmente es 32).
En segundo lugar, el valor hash de la clave primaria del objeto a almacenar también se obtiene de la misma forma y también se configura en este anillo.
Luego, a partir de la ubicación de los datos mapeados, los datos se buscan en el sentido de las agujas del reloj y se distribuyen al primer nodo de servidor encontrado.
La ventaja del hash consistente es que agregar y eliminar nodos solo afectará a los nodos vecinos en el anillo hash y no afectará a otros nodos.
Por lo tanto, el uso de hash consistente puede reducir la migración de datos durante la expansión del clúster.
Bien, esta vez lo comparto aquí. Es posible que nuestra práctica diaria solo utilice una de las soluciones, pero no es la imagen completa de la arquitectura de la base de datos. Sólo abriendo sus horizontes técnicos podrá hacer un mejor uso de las herramientas de almacenamiento.
Viejas reglas, un clic tres veces, dos mil al día, si te gusta, ¡obtendrás un millón de salario anual!
Autor: Jason
Veterano de Java con 7 años de experiencia, diseñador de temas de Xiaomi, diseñador de métodos de entrada de teléfonos móviles, conferenciante especial de ProcessOn.
He estado involucrado en investigación y desarrollo de aviación, telecomunicaciones, Internet de las cosas y productos de comercio electrónico vertical, y ahora trabajo para una reconocida empresa de comercio electrónico.
Maestro práctico de arquitecto de cuenta oficial técnica de WeChat, centrado en compartir información útil diaria sobre arquitectura, tecnología y lugar de trabajo, objetivo de Java: arquitecto.
¡Haz amigos y creced juntos!