1. ¿Por qué aparecen la subbase de datos y la subtabla?
¿Qué debo hacer si la cantidad de datos de la aplicación es demasiado grande y el servidor MySQL no puede admitirla?
Opción 1: mejorar las capacidades de procesamiento de datos mejorando las capacidades del hardware del servidor, como aumentar la capacidad de almacenamiento, la CPU, etc. Esta opción es muy costosa y, si el cuello de botella es el propio MySQL, mejorar el hardware también es muy costoso.
Opción 2: dispersar los datos en diferentes bases de datos para reducir la cantidad de datos en una sola base de datos y aliviar los problemas de rendimiento de una sola base de datos, logrando así el propósito de mejorar el rendimiento de la base de datos, como se muestra a continuación: dividir la base de datos de comercio electrónico en varias bases de datos independientes, y las tablas grandes también se dividen en varias tablas pequeñas. Este método de división de la base de datos puede resolver los problemas de rendimiento de la base de datos.
2. Cuatro formas de implementación de subbase de datos y subtabla
La subbase de datos y la subtabla incluyen dos partes: subbase de datos y subtabla. En producción, generalmente hay cuatro métodos: subbase de datos vertical, subbase de datos horizontal, subtabla vertical y subtabla horizontal.
mesa vertical
Divida una tabla en varias tablas según los campos y cada tabla almacena parte de los campos.
- Para evitar la contención de IO y reducir la posibilidad de que la tabla se bloquee, los usuarios que ven los detalles y la navegación por la información del producto no se afectan entre sí.
- Si aprovecha al máximo la eficiencia operativa de los datos populares, la alta eficiencia de las operaciones de información de productos no se verá obstaculizada por la baja eficiencia de las descripciones de productos.
Subbiblioteca vertical
Las tablas se clasifican según el negocio y se distribuyen en diferentes bases de datos. Cada base de datos se puede colocar en un servidor diferente. Su concepto central es que la base de datos es dedicada.
Las mejoras que trae son:
- Resolver el acoplamiento a nivel empresarial y dejar claro el negocio.
- Capacidad para realizar gestión jerárquica, mantenimiento, seguimiento, ampliación, etc. de datos de diferentes negocios
- En escenarios de alta concurrencia, la subbiblioteca vertical puede aumentar la cantidad de conexiones de base de datos y E/S hasta cierto punto y reducir el cuello de botella de los recursos de hardware de una sola máquina.
- La subbase de datos vertical clasifica las tablas por negocio y luego las distribuye en diferentes bases de datos, y estas bases de datos se pueden implementar en diferentes servidores, logrando así el efecto de compartir la presión en varios servidores, pero aún no resuelve el problema del volumen excesivo de datos. en una sola mesa. .
Subbiblioteca horizontal
Divide los datos de la misma tabla en diferentes bases de datos de acuerdo con ciertas reglas y cada base de datos se puede colocar en un servidor diferente.
Las mejoras que trae son:
- Resuelve el cuello de botella de rendimiento de big data de una sola base de datos y alta concurrencia.
- Mejora de la estabilidad y disponibilidad del sistema.
- Cuando es difícil segmentar verticalmente una aplicación con una granularidad más fina, o el número de filas de datos después de la segmentación es enorme y existen cuellos de botella en el rendimiento de lectura, escritura y almacenamiento de una sola base de datos, entonces es necesario Realizar segmentación horizontal. Después de la optimización de la segmentación horizontal, a menudo puede resolver el cuello de botella de capacidad de almacenamiento y rendimiento de una sola base de datos. Sin embargo, dado que la misma tabla se distribuye en diferentes bases de datos, se requiere trabajo de enrutamiento adicional para las operaciones de datos, lo que aumenta considerablemente la complejidad del sistema.
tabla de puntuación de nivel
En la misma base de datos, los datos de la misma tabla se dividen en varias tablas de acuerdo con ciertas reglas.
Las mejoras que trae son:
- Optimice los problemas de rendimiento causados por un volumen excesivo de datos en una sola tabla
- Evite la contención de IO y reduzca la posibilidad de bloqueos de mesa
- La división horizontal de tablas en la base de datos resuelve el problema del volumen excesivo de datos en una sola tabla. La tabla pequeña dividida solo contiene parte de los datos, lo que reduce el volumen de datos de una sola tabla y mejora el rendimiento de recuperación.
3. Soluciones técnicas comunes para subbases de datos y subtablas:
Las soluciones técnicas para fragmentar bases de datos y tablas generalmente se dividen en dos categorías: middleware de dependencia de capa de aplicación y middleware proxy de capa intermedia .
1. Middleware de clase dependiente de la capa de aplicación
La característica de este tipo de middleware de subbase de datos y subtabla es que está fuertemente acoplado con la aplicación y requiere que la aplicación dependa del paquete jar correspondiente (tomando Java como ejemplo), como el conocido TDDL. Dangdang código abierto sharding-jdbc, TSharding de Mogujie y Ctrip código abierto Ctrip-DAL, etc.
La idea básica de este tipo de middleware
es volver a implementar la API de JDBC, reimplementando las interfaces para operar la base de datos como DataSource y PrepareStatement, de modo que la capa de aplicación se pueda implementar de forma transparente sin cambiar el código comercial. (Nota: aquí se usa básico) La capacidad de crear subbases de datos y subtablas.
El middleware proporciona la conocida API JDBC a las aplicaciones de la capa superior y obtiene internamente SQL verdaderamente ejecutable a través de una serie de preparativos como el análisis de SQL, la reescritura de SQL y el enrutamiento de SQL. Luego, la capa inferior obtiene SQL físico utilizando métodos tradicionales (como la base de datos). grupos de conexiones) Conéctese para ejecutar SQL y, finalmente, combine los resultados de los datos en un ResultSet y devuélvalo a la capa de aplicación.
** Ventajas: ** No se requiere implementación adicional, simplemente publíquelo junto con el enlace de la aplicación
** Desventajas: ** No puede cruzar idiomas. Por ejemplo, sharding-jdbc escrito en Java obviamente no se puede usar en proyectos de C#, por lo que Ctrip dal También necesitamos reescribir un cliente C#.
2. Middleware proxy de capa intermedia
El principio básico de este tipo de middleware de subbase de datos y subtabla es configurar una capa de proxy entre la aplicación y la base de datos. La aplicación de la capa superior utiliza el protocolo MySQL estándar para conectarse a la capa de proxy, y luego el proxy La capa es responsable de reenviar la solicitud a la instancia física subyacente de MySQL. Este método solo tiene un requisito para la aplicación, que es que solo necesita usar el protocolo MySQL para comunicarse, por lo que un cliente puro como MySQL Workbench puede conectarse directamente a su base de datos distribuida y, naturalmente, es compatible con todos los lenguajes de programación. Los productos más representativos incluyen el innovador Amoeba, el Cobar de código abierto de Alibaba y Mycat, que tiene un desarrollo comunitario relativamente bueno.
Publicación de blog original y extensiones relacionadas:
Subbase de datos y subtabla: comparación de soluciones de middleware Subbase de datos y subtabla
TDDL : teoría y soluciones de transacciones distribuidas