Una arquitectura de base de datos madura no está diseñada para tener alta disponibilidad, alta escalabilidad y otras características desde el principio, sino que se mejora gradualmente a medida que aumenta el número de usuarios. Este artículo trata principalmente de los problemas y esquemas de optimización que enfrenta la base de datos MySQL en el ciclo de desarrollo, dejando de lado las aplicaciones front-end, se puede dividir a grandes rasgos en las siguientes cinco etapas:
Fase 1: diseño de la tabla de la base de datos
Una vez aprobado el proyecto, el departamento de desarrollo desarrolla el proyecto de acuerdo con las necesidades del departamento de producto.
El ingeniero de desarrollo diseñará la estructura de la mesa al comienzo del proyecto de desarrollo. Para la base de datos, el diseño de la estructura de la tabla es muy importante. Si el diseño es incorrecto, afectará directamente la velocidad de acceso de los usuarios al sitio web, ¡y la experiencia del usuario no es buena! Hay muchos factores específicos que afectan esta situación, como consultas lentas (declaraciones de consulta ineficientes), indexación incorrecta y congestión de la base de datos (bloqueos). Por supuesto, hay un equipo en el departamento de pruebas que realizará pruebas de productos y encontrará errores.
Debido a los diferentes puntos de énfasis, los ingenieros de desarrollo no considerarán si demasiados diseños de bases de datos son razonables en la etapa inicial, sino que completarán la implementación y entrega de la función lo antes posible. Después de que el proyecto esté en línea y tenga una cierta cantidad de visitas, los problemas ocultos quedarán expuestos, ¡en este momento no es tan fácil modificarlo!
Fase 2: implementación de la base de datos
Es hora de que salga el ingeniero de operación y mantenimiento y el proyecto se ponga en marcha.
Al comienzo del proyecto, el número de visitas es generalmente muy reducido. En esta etapa, el despliegue de una única base de datos Web + es suficiente para hacer frente a un QPS (tasa de consultas por segundo) de alrededor de 1000. Teniendo en cuenta un solo punto de falla, se debe lograr una alta disponibilidad.La replicación maestro-esclavo de MySQL + Keepalived se puede usar para lograr una copia de seguridad en caliente de sistema dual. El software de HA convencional incluye: Keepalived (recomendado) y Heartbeat.
Fase 3: optimización del rendimiento de la base de datos
Si MySQL se implementa en un servidor X86 normal, sin ninguna optimización, el valor teórico de MySQL normalmente puede manejar alrededor de 1500 QPS. Después de la optimización, puede aumentar a alrededor de 2000 QPS. De lo contrario, cuando el número de visitas alcanza alrededor de 1500 conexiones simultáneas, el rendimiento del procesamiento de la base de datos puede tardar en responder y los recursos de hardware aún son relativamente abundantes, es hora de considerar los problemas de optimización del rendimiento. Entonces, ¿cómo hacer que la base de datos tenga el máximo rendimiento? Se parte principalmente de los aspectos de la configuración del hardware, la configuración de la base de datos y la arquitectura, que se dividen específicamente en lo siguiente:
3.1 Configuración de hardware
Si es posible, las unidades de estado sólido SSD deben reemplazar los discos duros mecánicos SAS y ajustar el nivel de RAID a RAID1 + 0, que tiene un mejor rendimiento de lectura y escritura que RAID1 y RAID5. Después de todo, la presión sobre la base de datos proviene principalmente de la E / S del disco .
El kernel de Linux tiene una función que divide el área de caché (caché del sistema y caché de datos) de la memoria física para almacenar datos activos, y utiliza el mecanismo de escritura de retardo del sistema de archivos para esperar condiciones (como el tamaño del área de caché para alcanzar un cierto porcentaje o ejecutar el comando de sincronización) se sincronizará con el disco. Es decir, cuanto mayor sea la memoria física, mayor será el área de búfer asignada y más datos almacenados en caché. Por supuesto, una cierta cantidad de datos almacenados en caché se perderá si el servidor falla. Se recomienda que la memoria física sea al menos un 50% más rica.
3.2 Optimización de la configuración de la base de datos
MySQL tiene dos motores de almacenamiento más utilizados: uno es MyISAM, que no admite procesamiento de transacciones, procesamiento de rendimiento de lectura rápido y bloqueos a nivel de tabla. El otro es InnoDB, que admite el procesamiento de transacciones (atributos ACID). El objetivo del diseño es procesar big data con bloqueos a nivel de fila.
Bloqueo de tabla: baja sobrecarga, gran granularidad de bloqueo, alta probabilidad de interbloqueo y baja concurrencia relativa.
Bloqueo de fila: alta sobrecarga, pequeña granularidad de bloqueo, baja probabilidad de interbloqueo y alta concurrencia relativa.
¿Por qué hay bloqueos de mesa y bloqueos de fila? Principalmente para garantizar la integridad de los datos. Por ejemplo, si un usuario está operando una mesa y otros usuarios quieren operar la mesa, entonces es necesario esperar a que el primer usuario complete la operación antes de que otros usuarios puedan operarla. Los bloqueos de mesa y los bloqueos de fila sirven para este propósito. De lo contrario, si varios usuarios operan una mesa al mismo tiempo, definitivamente se producirán conflictos de datos o anomalías.
Según estos aspectos, utilizar el motor de almacenamiento InnoDB es la mejor opción, y también es el motor de almacenamiento predeterminado para MySQL 5.5+. Hay muchos parámetros operativos relacionados con cada motor de almacenamiento. Los parámetros que pueden afectar el rendimiento de la base de datos se enumeran a continuación.
Valores predeterminados de los parámetros públicos:
Valores predeterminados de los parámetros de MyISAM:
Valor predeterminado del parámetro InnoDB:
3.3 Optimización de los parámetros del kernel del sistema
La mayoría de MySQL se implementa en el sistema Linux, por lo que algunos parámetros del sistema operativo también afectarán el rendimiento de MySQL, la siguiente optimización de los parámetros del kernel de Linux
Fase 4: Extensión del esquema de la base de datos
Con el aumento del volumen de negocios, el rendimiento de un solo servidor de base de datos ya no puede satisfacer las necesidades comerciales, y es hora de considerar agregar una arquitectura de expansión de servidor. La idea principal es descomponer la carga de una sola base de datos, superar el rendimiento de E / S del disco, almacenar datos activos en la caché y reducir la frecuencia de acceso de E / S del disco.
4.1 aumentar la caché
Agregue un sistema de caché a la base de datos para almacenar en caché datos calientes en la memoria.Si hay datos solicitados en el caché, ya no solicite MySQL, reduciendo la carga de la base de datos. La implementación de la caché incluye caché local y caché distribuida. La caché local almacena datos en la memoria o archivos del servidor local. La caché distribuida puede almacenar en caché una gran cantidad de datos con buena escalabilidad. Los sistemas de caché distribuida principales: memcached, redis, memcached tienen un rendimiento estable, caché de datos en la memoria y la velocidad es muy rápida, la teoría QPS puede alcanzar alrededor de 8w. Si desea persistencia de datos, elija redis, el rendimiento no es inferior al de memcached.
Proceso de trabajo:
4.2 Replicación maestro-esclavo y separación de lectura y escritura
En un entorno de producción, los sistemas empresariales suelen leer más y escribir menos, y pueden implementar una arquitectura maestro-esclavo múltiple. La base de datos maestra es responsable de las operaciones de escritura y realiza copias de seguridad en caliente del sistema dual. Varias bases de datos esclavas realizan el equilibrio de carga y son responsables para operaciones de lectura. Equilibradores de carga convencionales: LVS, HAProxy, Nginx.
¿Cómo lograr la separación de lectura y escritura? La mayoría de las empresas logran separar la lectura y la escritura a nivel de código, lo que es muy eficiente. Otra forma es realizar la separación de lectura y escritura a través del programa del agente Hay menos aplicaciones en la empresa, lo que aumentará el consumo de middleware. Los sistemas principales de agentes de middleware incluyen MyCat, Atlas, etc.
En esta topología de replicación maestro-esclavo de MySQL, la carga de una sola máquina está dispersa, lo que mejora enormemente la concurrencia de la base de datos. Si un servidor esclavo puede manejar 1500 QPS, entonces tres pueden manejar 4500 QPS, y es fácil de escalar horizontalmente.
A veces, cuando se enfrenta a una gran cantidad de operaciones de escritura, el rendimiento de escritura de una sola máquina no puede cumplir con los requisitos comerciales. Puede realizar una replicación bidireccional (maestro dual), pero hay un problema: si dos servidores maestros proporcionan operaciones de lectura y escritura externas, es posible que encuentren inconsistencias en los datos. La razón de esto es que el programa tiene la posibilidad de operar dos bases de datos Al mismo tiempo, las operaciones de actualización simultáneas causarán conflictos o inconsistencias entre las dos bases de datos.
El campo de ID de cada tabla se puede configurar para que sea único: auto_increment_increment y auto_increment_offset. También puede escribir un algoritmo para generar un único aleatorio.
También se puede considerar el clúster oficial MGR (Multi-Master Replication) lanzado en los últimos dos años.
4.3 Subbiblioteca
La subbase de datos consiste en separar las tablas relacionadas de la base de datos en diferentes bases de datos de acuerdo con el negocio, como web, bbs, blog y otras bibliotecas. Si el volumen de negocio es grande, la base de datos separada también se puede utilizar como una arquitectura de replicación maestro-esclavo para evitar una presión excesiva sobre una sola base de datos.
4.4 Subtabla
El aumento dramático diario en el volumen de datos, hay millones de datos en una tabla en la base de datos, lo que resulta en un tiempo de consulta e inserción demasiado largo, ¿cómo podemos resolver la presión de una sola tabla? Debería considerar dividir esta tabla en varias tablas pequeñas para reducir la presión en una sola tabla y mejorar la eficiencia del procesamiento.Este método se denomina subtabla.
La tecnología de división de tablas es más problemática. Para modificar la instrucción SQL en el código del programa, debe crear manualmente otras tablas. También puede utilizar el motor de almacenamiento combinado para implementar la división de tablas, que es relativamente simple. Después de la subtabla, el programa debe operar en una tabla de totales. Esta tabla de totales no almacena datos, solo algunas relaciones de subtabla y la forma de actualizar los datos. La tabla de totales dividirá la presión en diferentes tablas pequeñas según diferentes consultas., mejorando así la concurrencia y el rendimiento de E / S del disco.
La tabla dividida se divide en división vertical y división horizontal: división
vertical: divide la tabla original con muchos campos en varias tablas para resolver el problema del ancho de la tabla. Puede colocar los campos que se utilizan con poca frecuencia en una sola tabla, o poner campos grandes en una tabla de forma independiente, o poner campos estrechamente relacionados en una tabla.
División horizontal: divide la tabla original en varias tablas, cada una de las cuales tiene la misma estructura, para resolver el problema del gran volumen de datos en una sola tabla.
4.5 Partición
La partición consiste en dividir los datos de una tabla en varios bloques de acuerdo con los campos de la estructura de la tabla (como rango, lista, hash, etc.). Estos bloques pueden estar en un disco o en diferentes discos. Después de la partición, la superficie Lo anterior sigue siendo una tabla, pero los datos están codificados en varias ubicaciones. De esta manera, varios discos duros procesan diferentes solicitudes al mismo tiempo, mejorando así el rendimiento de lectura y escritura de E / S del disco.
Nota: El aumento de caché, subbase de datos, subtabla y partición lo realiza principalmente el programador o DBA.
Fase cinco: mantenimiento de la base de datos
El mantenimiento de la base de datos es el trabajo de un ingeniero de base de datos o un ingeniero de operación y mantenimiento, que incluye la supervisión del sistema, el análisis del rendimiento, el ajuste del rendimiento, la copia de seguridad y la recuperación de la base de datos y otras tareas importantes.
5.1 Indicadores clave del estado de desempeño
5.2 Habilitar el registro de consultas lentas
MySQL abre el registro de consultas lento, analiza qué declaración SQL es más lenta y admite la apertura dinámica:
5.3 Copia de seguridad de la base de datos
Hacer una copia de seguridad de la base de datos es el trabajo más básico y el más importante; de lo contrario, las consecuencias serán graves, ¡ya sabes! Para una estrategia de respaldo de alta frecuencia, es importante elegir una herramienta estable y rápida. El tamaño de la base de datos está dentro de 2G, se recomienda utilizar la herramienta oficial de respaldo lógico mysqldump. Para más de 2G, se recomienda utilizar la herramienta de copia de seguridad física xtrabackup de percona, de lo contrario será tan lento como un caracol. Ambas herramientas admiten copias de seguridad en caliente bajo el motor de almacenamiento InnoDB y no afectan las operaciones comerciales de lectura y escritura.
5.4 Reparación de la base de datos
A veces, el servidor MySQL se apaga repentinamente o se apaga de manera anormal, lo que hará que la tabla se dañe y los datos de la tabla no se puedan leer. En este momento, puede usar las dos herramientas que vienen con MySQL para reparar, myisamchk y mysqlcheck. El primero solo puede reparar tablas MyISAM y detener la base de datos, mientras que el segundo puede repararse en línea, tanto MyISAM como InnoDB.
Nota: Es mejor hacer una copia de seguridad de la base de datos antes de realizar la reparación.
5.5 Análisis de rendimiento del servidor MySQL
Concéntrese en:
id: porcentaje de utilización de la CPU, un promedio inferior al 60% es normal, pero ya está ocupado.
wa: la CPU espera el tiempo de respuesta de E / S del disco, generalmente mayor que 5 indica que el volumen de lectura y escritura del disco es grande. 
KB_read / s, KB_wrtn / s La cantidad de datos leídos y escritos por segundo, principalmente basada en la velocidad máxima de lectura y escritura del disco por segundo.
r / s, w / s: número de solicitudes de lectura y escritura por segundo, que puede entenderse como IOPS (entrada y salida por segundo), que es uno de los principales indicadores para medir el rendimiento del disco.
aguardar: el tiempo medio de respuesta de E / S por segundo, generalmente superior a 5, indica que la respuesta del disco es lenta y supera su propio rendimiento.
util: El porcentaje de utilización del disco, que es menos del 60% en promedio, es normal, pero ya está ocupado.
resumen
Debido a las limitaciones del diseño original de las bases de datos relacionales, parecerá impotente cuando se trate de big data. Por lo tanto, NoSQL (base de datos no relacional) se ha vuelto popular. Es intrínsecamente inspirador y tiene las características de distribución, alto rendimiento y alta confiabilidad. Compensa las deficiencias inherentes de las bases de datos relacionales y es muy adecuado para almacenar datos no estructurados. Las bases de datos NoSQL convencionales incluyen: MongoDB, HBase, Cassandra, etc.
No es obvio que se mejore el efecto de optimización a nivel de la base de datos, lo principal es elegir la base de datos adecuada según el escenario empresarial.
Este artículo se publicó por primera vez: https://blog.51cto.com/lizhenliang/2095526