Primero, el cuello de botella de la base de datos
Ya sea que se trate de un cuello de botella de E / S o un cuello de botella de la CPU, eventualmente conducirá a un aumento en el número de conexiones activas en la base de datos, y luego se acercará o incluso alcanzará el umbral del número de conexiones activas que la base de datos puede transportar. En términos de servicios empresariales, hay pocas o ninguna conexión de base de datos disponible. Entonces puedes imaginarlo (concurrencia, rendimiento, bloqueo).
1. IO cuello de botella
El primero: el cuello de botella de IO de lectura de disco, demasiados datos calientes, la caché de la base de datos no se puede colocar, cada consulta generará una gran cantidad de IO, reducirá la velocidad de consulta-> sub-biblioteca y subtabla vertical.
El segundo tipo: cuello de botella de E / S de red, demasiados datos solicitados, ancho de banda de red insuficiente-> sub-biblioteca.
2. cuello de botella de la CPU
El primer tipo: los problemas de SQL, como SQL contiene unir , agrupar, ordenar por, consulta de condición de campo no indexada, etc., aumentan el funcionamiento de las operaciones de CPU-> optimización de SQL, establecen un índice adecuado y realizan cálculos empresariales en la capa de Servicios empresariales.
El segundo tipo: la cantidad de datos en una sola tabla es demasiado grande, se escanean demasiadas filas durante la consulta, la eficiencia de SQL es baja y la CPU es la primera en tener un cuello de botella-> división de tabla horizontal.
2. Subbiblioteca y subtabla
1. Sub-biblioteca horizontal
Concepto: según el campo, de acuerdo con una determinada estrategia (hash, rango, etc.), los datos de una biblioteca se dividen en varias bibliotecas.
El resultado:
-
La estructura de cada biblioteca es la misma;
-
Los datos de cada biblioteca son diferentes, no hay intersección;
-
La unión de todas las bibliotecas son datos completos;
Escenario: La concurrencia absoluta del sistema está activa, es difícil resolver el problema fundamentalmente y no existe una atribución comercial obvia para dividir la biblioteca verticalmente.
Análisis: con más bibliotecas, la presión de io y cpu puede aliviarse naturalmente por múltiples.
2. Tabla de niveles
Concepto: según el campo, de acuerdo con una determinada estrategia (hash, rango, etc.), divida los datos en una tabla en varias tablas.
El resultado:
-
La estructura de cada tabla es la misma;
-
Los datos de cada tabla son diferentes, no hay intersección;
-
La unión de todas las tablas son datos completos;
Escenario: el volumen concurrente absoluto del sistema no ha surgido, pero la cantidad de datos en una sola tabla es demasiado, lo que afecta la eficiencia de SQL y aumenta la carga de la CPU, por lo que se convierte en un cuello de botella. Recomendación: Análisis del principio de optimización de una consulta SQL.
Análisis: La cantidad de datos en la tabla se reduce y la eficiencia de la ejecución de SQL único es alta, lo que naturalmente reduce la carga sobre la CPU.
3. Sub-biblioteca vertical
Concepto: según la tabla, de acuerdo con las diferentes atribuciones comerciales, divida las diferentes tablas en bibliotecas diferentes.
El resultado:
-
La estructura de cada biblioteca es diferente;
-
Los datos de cada biblioteca también son diferentes, no hay intersección;
-
La unión de todas las bibliotecas son datos completos;
Escenario: el volumen concurrente absoluto del sistema está activo y se puede abstraer un módulo comercial separado.
Análisis: En esta etapa, básicamente se puede reparar. Por ejemplo, con el desarrollo del negocio, hay cada vez más tablas de configuración comunes, tablas de diccionario, etc. En este momento, estas tablas se pueden dividir en bibliotecas separadas e incluso se pueden reparar. Además, con el desarrollo del negocio, se tramó un conjunto de modelos de negocio. En este momento, las tablas relacionadas se pueden desarmar en una biblioteca separada e incluso se pueden reparar.
4. Mesa vertical
Concepto: según el campo, de acuerdo con la actividad del campo, los campos de la tabla se dividen en diferentes tablas (tabla principal y tabla extendida).
El resultado:
-
La estructura de cada tabla es diferente;
-
Los datos de cada tabla también son diferentes: en general, los campos de cada tabla tienen al menos una intersección de columna, que generalmente es la clave principal, que se utiliza para correlacionar datos;
-
La unión de todas las tablas son datos completos;
Escenario: no ha surgido la concurrencia absoluta del sistema. No hay muchos registros en la tabla, pero hay muchos campos, y los datos activos y los no activos están juntos. El espacio de almacenamiento requerido para una sola fila de datos es grande. Como resultado, se reduce el número de filas de datos en caché por la base de datos, y se generará una gran cantidad de IO de lectura aleatoria al leer los datos del disco durante la consulta, lo que resulta en un cuello de botella de IO.
Análisis: las páginas de lista y las páginas de detalles se pueden utilizar para ayudar a comprender. El principio de la división vertical de tablas es colocar los datos de puntos calientes (datos que pueden consultarse juntos frecuentemente) como la tabla principal, y los datos que no son puntos calientes como la tabla extendida. De esta manera, se pueden almacenar en caché más datos de puntos de acceso, lo que reduce la E / S de lectura aleatoria. Después del desmantelamiento, para obtener todos los datos, debe asociar dos tablas para obtener los datos.
Pero recuerde, no use join, porque join no solo aumentará la carga de la CPU y hablará de dos tablas juntas (deben estar en una instancia de base de datos). Datos relacionados, debe hacer un artículo en la capa de Servicios empresariales, obtener la tabla principal y los datos de la tabla extendida por separado y luego usar los campos relacionados para obtener todos los datos.
3. Sub-base de datos y herramientas de subtabla
-
sharding-sphere: jar, anteriormente sharding-jdbc;
-
TDDL ： jar ， Taobao Distribuir capa de datos ；
-
Mycat: middleware.
Nota: los pros y los contras de la herramienta, haga su propia investigación, el sitio web oficial y la prioridad de la comunidad.
4. Sub-biblioteca y pasos de tabla
De acuerdo con la capacidad (capacidad actual y crecimiento), evalúe el número de sub-bibliotecas o sub-tablas-> tecla de selección (par) -> reglas de tabla (hash o rango, etc.) -> ejecutar (generalmente doble escritura) -> problema de expansión (reduzca lo más posible) Movimiento de datos).
Extensión: MySQL: la diferencia y el pensamiento de la subtabla y sub-base de datos
Quinto, el problema de la sub-biblioteca y la tabla.
1. Problema de consulta de clave sin partición
Basado en la sub-biblioteca horizontal y la sub-tabla, la estrategia de división es el método hash comúnmente usado.
Además de la clave de partición, solo hay una clave sin partición como consulta condicional
Método de mapeo
Método genético
Nota: Al escribir, el método genético genera user_id, como se muestra en la figura. Con respecto al gen xbit, por ejemplo, hay 8 tablas, 23 = 8, entonces x toma 3, que es el gen de 3 bits. De acuerdo con la consulta user_id, puede tomar directamente la ruta modular a la sub-biblioteca o subtabla correspondiente.
Al realizar consultas basadas en user_name, primero genere user_name_code a través de la función de generación user_name_code y luego tome la ruta del módulo a la subbiblioteca o subtabla correspondiente. La generación de identificación utiliza habitualmente el algoritmo de copo de nieve.
Además de la clave de partición, hay más de una clave de no partición como consulta condicional
Método de mapeo
Broma
Nota: Diríjase a la biblioteca db_o_buyer cuando realice consultas por order_id o buyer_id, y diríjase a la biblioteca db_o_seller cuando realice consultas por seller_id. Se siente un poco al revés! ¿Hay alguna otra buena manera? ¿Qué hay de cambiar la pila de tecnología?
Además de la clave de partición, hay varias consultas de condición de combinación de clave sin partición en segundo plano
Método NoSQL
Broma
2. Problema de consulta de paginación de tabla cruzada entre bases de datos sin clave de partición
Basado en la sub-biblioteca horizontal y la sub-tabla, la estrategia de división es el método hash comúnmente usado.
Nota: Método NoSQL (ES, etc.).
3. Expansión de capacidad
Basado en la sub-biblioteca horizontal y la sub-tabla, la estrategia de división es el método hash comúnmente usado.
Biblioteca de expansión horizontal (actualización del método de biblioteca)
Nota: La expansión se duplica.
Tabla de expansión horizontal (método de migración de doble escritura)
-
El primer paso: (doble escritura sincrónica) modificar la configuración y el código de la aplicación, además de la doble escritura, implementación;
-
El segundo paso: (doble escritura síncrona) copie los datos antiguos de la biblioteca anterior a la nueva biblioteca;
-
El tercer paso: (Escritura doble sincrónica) Revise los datos antiguos en la nueva biblioteca basándose en la biblioteca anterior;
-
El cuarto paso: (doble escritura síncrona) modifica la configuración y el código de la aplicación, elimina la doble escritura, despliega;
Nota: la doble escritura es un esquema general.
Seis, resumen de subbiblioteca y subtabla
-
Para dividir la biblioteca en tablas, primero debe saber dónde está el cuello de botella, y luego puede dividirlo razonablemente (sub-biblioteca o tabla? Horizontal o vertical? ¿Cuántos?). Y no se puede dividir para dividir la biblioteca y la tabla.
-
Elegir una clave es muy importante, no solo para considerar la división de manera uniforme, sino también para considerar las consultas de clave sin partición.
-
Mientras se cumplan los requisitos, cuanto más simple sea la regla de división, mejor.
