Selección e implementación de la arquitectura de la base de datos, solo lea este artículo
Con el desarrollo del tiempo y los negocios, la cantidad de datos en la base de datos crece incontrolablemente. Los datos en la base de datos y las tablas se harán cada vez más grandes, lo que generará mayores requisitos de disco y IO y sobrecarga del sistema. , e incluso cuellos de botella en el rendimiento, y los recursos de un solo servidor son limitados después de todo.
Por lo tanto, en el proceso de expansión empresarial, las aplicaciones han planteado requisitos más altos para la robustez, seguridad y escalabilidad del sistema de base de datos.
A continuación, le presentaré la arquitectura, selección e implementación de la base de datos.
¿Qué desafíos enfrentará la base de datos?
Al comienzo del negocio, solo usábamos una base de datos de una sola máquina, pero 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 y almacenamiento. cuellos de botella, disponibilidad y problemas de seguridad.
Para resolver los problemas mencionados anteriormente, la base de datos ha derivado diferentes arquitecturas para resolver las necesidades de diferentes escenarios.
Separe las operaciones de escritura y lectura de la base de datos. La base de datos maestra recibe solicitudes de escritura y utiliza múltiples copias de la base de datos esclava para hacerse cargo de las solicitudes de lectura. La base de datos esclava y la base de datos maestra actualizan los datos sincrónicamente para mantener los datos. Consistencia La base de datos esclava puede expandirse horizontalmente para enfrentar un aumento en las solicitudes de lectura.
Este modo también se conoce comúnmente como separación de lectura y escritura. Está dirigido a datos de pequeña escala y escenarios donde hay 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 para proporcionar escrituras en la base de datos maestra, 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 la IO se concentra en una determinada parte del negocio, ¿qué puede ocurrir? Lo que se considera en este momento es que la subbiblioteca vertical divide los negocios de puntos de acceso para evitar que las solicitudes intensivas de E/S de los negocios de puntos de acceso afecten a otros negocios normales. Por lo tanto, la subbiblioteca vertical también se denomina subbiblioteca de negocios.
Ventajas:
Desventajas:
Cuando la base de datos encuentra un cuello de botella de almacenamiento, el rendimiento del índice disminuye debido al volumen excesivo de datos.
En este momento, puede considerar dividir los datos horizontalmente. Para una sola tabla con una gran cantidad de datos, divídala en varias tablas de acuerdo con ciertas reglas.
Sin embargo, estas tablas todavía están en la misma base de datos, por lo que las operaciones de la base de datos a nivel de base de datos todavía tienen cuellos de botella de IO (la IO de un solo servidor tiene un límite superior).
Por lo tanto, la fragmentación horizontal de tablas está dirigida principalmente a escenarios donde la cantidad de datos es grande y el volumen general de solicitudes comerciales es bajo.
Ventajas:
Desventajas:
4. Subbase de datos y subtabla
Cuando la base de datos encuentra cuellos de botella de almacenamiento y cuellos de botella de IO El volumen excesivo de datos hace que el rendimiento del índice disminuya. Además, las solicitudes comerciales a gran escala deben procesarse al mismo tiempo. En este momento, el límite superior de IO de una sola 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 la recopilación de datos en la tabla es diferente.
Las subbases de datos y las subtablas pueden aliviar eficazmente los cuellos de botella en el rendimiento y las presiones de máquinas individuales y bases de datos únicas, y superar los cuellos de botella de IO, cantidad de conexiones, recursos de hardware, etc.
Ventajas:
Desventajas:
Nota: La clave para saber si la subbase de datos o la subtabla es si hay un cuello de botella de IO.
¿Cuáles son los métodos de fragmentación?
RANGE (fragmentación de rango)
Después de ordenar un determinado campo clave en la tabla de negocios, el orden es de 0 a 10000 para una tabla y de 10001 a 20000 para una tabla. La más común es dividirlo según el tiempo (tabla mensual, tabla cronológica).
Por ejemplo, recorte los datos de hace 6 meses o incluso de hace un año y colóquelos en otra tabla, porque a medida que pasa el tiempo, la probabilidad de que se consulten los datos de estas tablas se vuelve menor y el banco transacciones La mayoría de los registros se registran de esta manera.
Ventajas:
Desventajas:
HASH (Hash sharding)
Utilice pedidos como tabla principal y luego relacionados La tabla de negocios se utiliza como tabla complementaria. Se toma el ID de usuario y luego se aplica un hash para tomar el módulo y asignarlo a diferentes tablas de datos o bases de datos.
Ventajas:
Desventajas:
En este punto ya sabemos qué arquitectura tiene la base de datos y qué problemas resuelve, por lo que en nuestro diseño diario es diferente. Las arquitecturas deben seleccionarse en función de las características de los datos, las tendencias de los datos, la seguridad de los datos, etc.
Entonces, ¿cómo debemos elegir la arquitectura de la base de datos?
Aunque la combinación de todas las arquitecturas anteriores puede 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 los problemas de todos los escenarios, también enfrentará más desafíos. Lo que usted cree que es una arquitectura perfecta en realidad tiene más trampas detrás.
1. Soporte para transacciones
Después de dividir la base de datos en tablas (ya sea división vertical u horizontal), se convierte en una transacción distribuida si depende de la transacción distribuida de. la base de datos en sí La función de administración pagará un alto precio de rendimiento (transacción XA) para ejecutar la transacción, si la aplicación ayuda en el control y forma una transacción en la lógica del programa, causará una carga de programación (TCC, SAGA).
2. Fusionar múltiples conjuntos de resultados de bases de datos (agrupar por, ordenar por)
Dado que los datos se distribuyen en diferentes bases de datos, es imposible realizar directamente operaciones como paginación, agrupación, y ordenarlo. Generalmente, las operaciones de consulta que se ocupan de la fusión de conjuntos de resultados de múltiples bases de datos deben utilizar otros medios, como la limpieza y sincronización de datos (TIDB, KUDU, etc.).
3. Retraso de datos
El mecanismo de copia múltiple bajo la arquitectura maestro-esclavo y la base de datos agregada después de la fragmentación horizontal tendrán el problema de retraso entre los datos maestros y los datos de réplica.
4. Unión entre bases de datos
Después de dividir la base de datos en tablas, las operaciones de asociación entre tablas estarán restringidas no podremos unir tablas ubicadas en diferentes bases de datos (verticalmente), ni tampoco. ¿Podemos unir tablas divididas con diferentes granularidades de tabla (niveles)? Como resultado, un negocio que se puede completar con una consulta puede requerir varias consultas para completarse.
5. Expansión de fragmentación
Después de la fragmentación horizontal, una vez que se necesita expansión. Los datos correspondientes deben migrarse una vez, lo que resulta extremadamente costoso.
6. Generación de ID
Dado que la base de datos es independiente después de dividirla en tablas, la ID de aumento automático basada en la base de datos ya no se puede utilizar en este momento. , es necesario utilizar otras soluciones de generación de ID externas.
1. Clase de dependencia de la capa de aplicación (JDBC)
La característica de este tipo de middleware de subbiblioteca y subtabla es que está fuertemente acoplado con la aplicación, y la aplicación debe depender explícitamente del paquete jar correspondiente (en Java, por ejemplo), como el conocido TDDL, el código abierto Dangdang sharding-jdbc, el TSharding de Mogujie, etc.
La idea básica de este tipo de middleware es volver a implementar la API de JDBC, reimplementando interfaces como DataSource y PrepareStatement para operar la base de datos, de modo que la capa de aplicación pueda implementar de forma transparente. subbiblioteca sin cambiar básicamente el código comercial. La capacidad de dividir tablas.
El middleware proporciona la conocida API JDBC a las aplicaciones de la capa superior e internamente obtiene SQL verdaderamente ejecutable a través de una serie de preparativos como análisis de SQL, reescritura de SQL, enrutamiento de SQL, etc., y luego la capa inferior. sigue el método tradicional (por ejemplo, grupo de conexiones de base 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 subbase de datos y middleware de tabla Configura una capa de proxy entre la aplicación y la base de datos. La aplicación superior utiliza el protocolo MySQL estándar para conectarse a la capa de proxy, y luego la capa de proxy es responsable de reenviar la solicitud a la instancia física de MySQL subyacente. Solo hay un requisito para la aplicación, que es simplemente utilizar el protocolo MySQL para comunicarse.
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, además de ser básicamente similar al middleware dependiente de la capa de aplicación, la subbase de datos de clase proxy y los productos de tabla deben implementar el protocolo MySQL estándar. En cierto sentido, lo que es un proxy de base de datos. La capa de reenvío es la solicitud del protocolo MySQL, al igual que Nginx reenvía la solicitud del protocolo HTTP.
Los productos más representativos incluyen el innovador Amoeba, el Cobar de código abierto de Alibaba y Mycat (desarrollado en base a Cobar), que tiene un buen desarrollo comunitario, etc.
Ventajas
Desventajas
Solución JDBC: arquitectura descentralizada, compatible con la mayoría de bases de datos relacionales del mercado, adecuada para desarrollar aplicaciones OLTP ligeras de alto rendimiento (frontend ).
Solución proxy: proporciona entrada estática y soporte de lenguaje heterogéneo, adecuado para aplicaciones OLAP (orientadas a backend) y escenarios para la gestión y operación de bases de datos fragmentadas.
Solución híbrida: en sistemas grandes y complejos, existen aplicaciones front-end para usuarios C-end y aplicaciones back-end para análisis empresarial. En este caso, se puede adoptar un modelo híbrido.
JDBC adopta una arquitectura descentralizada y es adecuado para aplicaciones OLTP livianas de alto rendimiento desarrolladas en Java; Proxy proporciona entrada estática y soporte de lenguaje heterogéneo, y es adecuado para aplicaciones OLAP y administración de bases de datos fragmentadas y operación. escenarios de mantenimiento.
ShardingSphere es un ecosistema compuesto por un conjunto de soluciones de middleware de bases de datos distribuidas de código abierto. Consta de tres productos independientes: Sharding-JDBC, Sharding-Proxy y Sharding-Sidecar (planificado), todos proporcionan datos estandarizados. fragmentación, transacciones distribuidas y funciones de administración de bases de datos, y se puede aplicar a varios escenarios de aplicaciones diversos, como isomorfismo de Java, lenguajes heterogéneos, contenedores, nativos de la nube, etc.
Funciones principales proporcionadas por ShardingSphere:
Sharding-Proxy
Posicionado como un proxy de base de datos transparente, proporciona una versión de servidor que encapsula el protocolo binario de la base de datos utilizado. para completar el soporte para lenguajes heterogéneos.
Actualmente está disponible una versión de MySQL, que puede utilizar cualquier cliente de acceso compatible con el protocolo MySQL (como MySQL Command Client, MySQL Workbench, Navicat, etc.) para operar datos, haciéndolo más amigable para los DBA. .
Completamente transparente para la aplicación y se puede utilizar directamente como MySQL.
Aplicable a cualquier cliente compatible con el protocolo MySQL.
Sharding-JDBC
Posicionado como un marco Java 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 implementación ni dependencias adicionales. Puede entenderse como una versión mejorada del controlador JDBC, totalmente compatible con JDBC y varios marcos ORM.
Tomando como ejemplo el sistema SaaS de comercio electrónico, la aplicación front-end utiliza Sharding-JDBC, que se divide principalmente en tres soluciones según las diferencias en los escenarios comerciales.
Subbase de datos (usuario)
Análisis del problema: las empresas principales tienen una alta actividad diaria y una alta concurrencia. Las subbases de datos separadas pueden evitar interferir con otros usuarios empresariales. los datos no requieren tablas separadas.
Dimensión dividida: subbase de datos de ID empresarial
Estrategia dividida: base de datos separada para empresas líderes, una base de datos para empresas no principales
Subbase de datos y tabla (Pedidos)
Análisis del problema: los datos de los pedidos están creciendo rápidamente y es necesario dividirlos en tablas además de la base de datos.
División de dimensiones: subbase de datos de ID de empresa, subtabla de ID de usuario
Estrategia de división: base de datos separada para empresas principales, una base de datos para empresas no principales Después de dividir la base de datos. , se toma la ID de usuario Tabla dividida del módulo
Tabla dividida de base de datos única (adjunto)
Análisis del problema: los datos adjuntos se caracterizan por una pequeña cantidad de concurrencia y solo necesita resolver el El problema del crecimiento de los datos es suficiente, por lo que una sola base de datos IO es suficiente para soportar. En este caso, se puede dividir en tablas.
Dimensión dividida: ID de usuario en tabla
Estrategia dividida: ID de usuario en tabla en módulo
Pregunta 1: Transacción distribuida
Excesivamente Las transacciones distribuidas complejas también son el problema más difícil de abordar en los sistemas distribuidos. Debido al espacio limitado, nos centraremos en este tema más adelante.
Pregunta 2: ID distribuido
Pregunta 3: Consulta entre fragmentos
Por ejemplo, después de fragmentar por ID de usuario, debe consultar la empresa según el ID de empresa Toda la información del usuario.
La fragmentación también puede admitir consultas entre fragmentos. En esencia, las consultas entre fragmentos de fragmentación consultan datos de varios fragmentos al mismo tiempo y luego agregan los resultados y los devuelven. Este método consume muchos recursos. , especialmente el consumo de recursos de conexión a la base de datos.
Suponiendo 4 bases de datos y 8 tablas, la fragmentación emitirá 32 consultas SQL al mismo tiempo. Se consumieron 32 conexiones a la vez;
Especialmente cuando una sola base de datos se divide en tablas, tenga en cuenta que suponiendo que una sola base de datos se divida en 64 tablas, se consumirán 64 conexiones. Si implementamos 2 nodos, si los dos nodos consultan al mismo tiempo, encontraremos el límite superior de la cantidad de conexiones de base de datos (mysql por defecto es 100 conexiones)
Pregunta 4: expansión de fragmentación
A medida que crecen los datos, los datos de cada fragmento alcanzarán un cuello de botella. En este momento, es necesario aumentar el número original de fragmentos. Debido a la adición de sectores, las reglas de hash originales también cambiaron, lo que resultó en la necesidad de migrar datos antiguos.
Supongamos que los datos originales de 100 millones de hash se dividen en 64 tablas. Ahora ha aumentado a 5 mil millones de datos. Una vez que se expande la capacidad, los 5 mil millones de datos. Es necesario migrar. El costo de la migración es inimaginable.
Pregunta 5: Hash consistente
Primero, encuentre el valor hash de cada servidor y configúrelo en un anillo de 0~2^n (n suele ser 32)
En segundo lugar, utilice el mismo método para encontrar el valor hash de la clave principal del objeto que se almacenará y también configúrelo en este anillo.
Luego, busque en el sentido de las agujas del reloj a partir de la ubicación donde están asignados los datos y distribuya los datos al primer nodo del servidor encontrado.
La ventaja del hash consistente es que agregar y eliminar nodos solo afectará a los nodos adyacentes en el anillo hash, pero no 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.
Ok, esta vez lo comparto aquí. Es posible que solo usemos una de las soluciones en la práctica diaria, pero no es la imagen completa de la arquitectura de la base de datos. Solo abriendo la perspectiva técnica podemos mejorar. Utilice las herramientas de almacenamiento.
¡Sigue las viejas reglas, haz clic tres veces seguidas, gana dos mil al día, mira los Me gusta y obtén un salario anual de un millón!
Autor de este artículo: Jensen
Veterano de Java con 7 años de experiencia, diseñador de temas de Xiaomi, diseñador de métodos de entrada móviles, conferenciante especial de ProcessOn.
Ha estado involucrado en aviación, telecomunicaciones, IoT y desarrollo de productos de comercio electrónico vertical, y ahora trabaja para una reconocida empresa de comercio electrónico.
Cuenta pública técnica Registro de práctica del arquitecto El propietario de la cuenta se centra en compartir consejos diarios sobre arquitectura, tecnología y lugar de trabajo. Objetivos de Java: Arquitecto.
¡Haz amigos y creced juntos!