A principios del mes pasado, vi un artículo sobre la prueba de rendimiento del almacenamiento informático en el blog de Percona (consulte el enlace al final del artículo para obtener más detalles). Algunas de las características mencionadas en él despertaron mi interés, por lo que me expandí sobre informática Las tecnologías relacionadas con el almacenamiento descubrieron repentinamente que la computación y el almacenamiento para sistemas de bases de datos podrían resolver más o menos algunos cuellos de botella y puntos débiles, e incluso reducir significativamente el TCO sin afectar el rendimiento. ¿Qué tipo de características tienen tal poder mágico?
Vendamos una clave aquí. Hablaremos sobre el contenido mencionado en el artículo más adelante. Echemos un vistazo a los cuellos de botella y los puntos débiles que pueden encontrarse en la gestión del ciclo de vida del sistema de base de datos. Luego, presentaré cómo el almacenamiento informático puede resolver sistemáticamente estos cuellos de botella y puntos débiles.
PD: El siguiente contenido solo representa opiniones personales. Además, dado que estoy familiarizado con MySQL, a continuación se enumeran brevemente algunos puntos débiles típicos con el motor MySQL InnoDB como ejemplo.
1. ¿Cuáles son los cuellos de botella y los puntos débiles típicos en los sistemas de bases de datos?
Dos indicadores clave del rendimiento de la base de datos: (latencia) y el número de transacciones en paralelo (tps). Los dos se complementan entre sí y son inversamente proporcionales. Cuanto menor es la latencia de la transacción, mayores son los tps permitidos. Por el contrario, cuanto mayor es la latencia de la transacción, entonces Cuanto más bajos sean los tps permitidos. Cuanto mayor sea el tps, mejor será el rendimiento y, viceversa, menor será el rendimiento. La base de datos es muy sensible a la demora de respuesta de IO, que afecta directamente la demora de respuesta de la transacción, y la demora de respuesta de la transacción determina en gran medida los tps de la base de datos. Por lo tanto, en un escenario donde la base de datos MySQL se ejecuta en un servidor con especificaciones de hardware razonables y el índice MySQL está relativamente estandarizado, a menudo podemos ver que el primer cuello de botella es el subsistema IO
Centrándome en estos dos indicadores clave, he enumerado cuatro escenarios típicos donde pueden ocurrir cuellos de botella y puntos débiles, de la siguiente manera
1.1. La capacidad de almacenamiento de un solo servidor de base de datos es insuficiente
Capacidad de almacenamiento insuficiente
Solución tradicional
* Cuando el tiempo es escaso, puede eliminar archivos con frecuencia para dejar espacio para una solución temporal
* Cuando el presupuesto es suficiente, se puede reemplazar un dispositivo de almacenamiento de mayor capacidad para la migración de datos completa
* Cuando el presupuesto y el tiempo son suficientes, se pueden agregar más servidores para dividir los datos
La carga de almacenamiento es demasiado alta (el rendimiento es demasiado alto)
Soluciones tradicionales:
* Cuando hay poco tiempo, se puede solucionar temporalmente eliminando el proceso que consume la mayor cantidad de almacenamiento.
* Cuando el presupuesto sea suficiente, reemplace los dispositivos de almacenamiento con un ancho de banda de mayor rendimiento y realice una migración de datos completa
* Cuando el presupuesto y el tiempo son suficientes, se pueden agregar más servidores para dividir los datos
Desventajas:
Las soluciones temporales requieren una atención frecuente a las condiciones de carga de almacenamiento y, a menudo, descuidan una y otra.
Reemplazar piezas requiere costos adicionales. La división de datos aumenta la complejidad del negocio y los costos de mantenimiento, y también presenta algunos problemas nuevos (consulte "1.4. Un número excesivo de consultas simultáneas genera una alta carga de instancias de la base de datos" Las desventajas mencionadas en)
1.2. El servidor de la base de datos tiene memoria insuficiente
Soluciones tradicionales:
Limpie temporalmente los datos de tabla innecesarios o reduzca los valores de los parámetros de MySQL en varias asignaciones de caché para liberar más memoria y permitir que MySQL Server haga más cosas
Aumente la memoria física y aumente el valor de varios parámetros de asignación de búfer de MySQL
Desventajas:
Las soluciones temporales requieren una atención continua al uso de la memoria y las operaciones frecuentes. Además, esta es la práctica de cavar el muro este para complementar el muro oeste
El aumento de la memoria física, además de aumentar los costos, también tendrá un cierto impacto en el negocio (es necesario apagar el servidor)
1.3. Una sola transacción es demasiado grande, lo que da como resultado un rendimiento deficiente de las consultas
Solución tradicional: dividir grandes transacciones en pequeñas transacciones
Para transacciones grandes que no se pueden dividir, bajo la premisa de las mismas especificaciones de hardware, las transacciones de lectura y escritura se pueden optimizar por separado. Por ejemplo: Write puede cambiar el formato binlog a una declaración a nivel de sesión antes de la ejecución para reducir la cantidad de binlog transmitido entre las instancias maestra y esclava; las transacciones de lectura se pueden dividir en bibliotecas esclavas de solo lectura para reducir la presión de acceso de la biblioteca maestra
Desventajas:
Dividir una transacción grande en transacciones pequeñas no reduce la cantidad de tareas de trabajo que deben completarse en la transacción grande original, pero después de dividirla en transacciones pequeñas, reduce el impacto en otras transacciones paralelas (por ejemplo: las transacciones grandes pueden llevar mucho tiempo Retención de bloqueos, recursos de manejo de archivos de registro binario, etc., lo que resulta en un bloqueo a largo plazo de otras transacciones paralelas, lo que provoca una falla en la ejecución de transacciones paralelas)
1.4. Un número excesivo de consultas simultáneas genera una carga excesiva en la instancia de la base de datos
Soluciones tradicionales:
Elimine las sesiones de consulta de alta carga y, posteriormente, optimice las consultas lentas
Separación de lectura y escritura, aumento de la biblioteca esclava de solo lectura y ampliación de la capacidad de solo lectura
División de datos, distribución de datos a múltiples instancias de bases de datos, expansión de capacidades de lectura / escritura.
* Para dividir los datos de la tabla grande, primero haga la división vertical (por división comercial, dividir los campos de diferentes negocios en diferentes tablas, o diferentes bases de datos, o incluso diferentes instancias), y luego dividir horizontalmente ( Para las tablas que no pueden continuar dividiendo campos, si la cantidad de datos aún es lo suficientemente grande como para afectar el rendimiento, es posible que deba continuar dividiendo la tabla grande con el estándar de no más de 1000 W filas de datos, que es lo que a menudo llamamos fragmentación de datos).
Desventajas: ya sea que se trate de una división vertical u horizontal, se requiere la aplicación y la transformación correspondiente. Además, después de la división de datos, se introducirán nuevos puntos débiles, similares a los siguientes (aunque estos puntos débiles pueden resolverse mediante la transformación tecnológica, el costo es demasiado alto , Y lleva mucho tiempo ejecutarlo para que sea estable. Además, es posible que sea necesario profundizar en la transformación comercial, es posible que diferentes clientes necesiten realizar diferentes transformaciones): acceso entre particiones, lo que resulta en tener que habilitar transacciones distribuidas para Para garantizar la coherencia de los datos del acceso entre fragmentos, y la transacción distribuida en sí tiene una cierta cantidad de ingeniería para implementar, y la aplicación en sí también debe modificarse
Si los fragmentos abarcan diferentes instancias, no se puede lograr una copia de seguridad coherente global de los datos. Para lograr una copia de seguridad coherente de los datos globales en varios fragmentos de datos en todas las instancias, se requieren algunas transformaciones para el middleware y las bases de datos.
Las declaraciones DDL que no están bajo control de transacciones no pueden garantizar la coherencia global de los datos a través de transacciones distribuidas, por lo que se necesitan mecanismos adicionales para asegurar la coherencia global de los datos.
Si los datos fragmentados están sesgados o la carga de acceso está sesgada, también puede ser necesario migrar con frecuencia los datos fragmentados (migrar fragmentos con grandes volúmenes de datos, fragmentos en instancias de alta carga a instancias relativamente inactivas)
2. ¿Cómo resuelve el almacenamiento informático los cuellos de botella y los puntos débiles de las bases de datos?
Para el almacenamiento computacional, enumeraré tres características que creo que son más importantes. Primero, presentaré brevemente sus principios (para una introducción detallada de los principios relacionados, consulte el enlace al final del artículo) y luego hablaré sobre cómo estas características resuelven la base de datos mencionada anteriormente. Cuellos de botella y puntos débiles
La primera característica importante: el almacenamiento admite escrituras atómicas a nivel de hardware
¿Por qué la base de datos necesita escritura atómica?
* El tamaño de página predeterminado del archivo de datos InnoDB es 16k, y el tamaño de bloque predeterminado del sistema de archivos es 4k. Es decir, la unidad mínima de operación de IO del archivo de datos InnoDB es 16k, y la unidad mínima de operación IO del sistema de archivos es 4k. Cuando se escribe el archivo de datos InnoDB Cuando se envía una página de 16k al sistema de archivos, el sistema de archivos necesita descomponerla en 4 bloques de 4k y luego escribirlos en el dispositivo de almacenamiento. Dado que la mayoría de los sistemas de archivos no admiten escrituras atómicas, si ocurre un accidente (como un corte de energía) durante la escritura del sistema de archivos en el dispositivo de almacenamiento, puede causar que el tamaño de página de InnoDB se escriba parcialmente (corrompido), lo que provocará que MySQL Server falle. Inicio normal
* Para evitar este problema, InnoDB introdujo la función de escritura doble. ¿Para qué se usa la escritura doble? Cuando hay datos que deben escribirse en el archivo de datos (es decir, vaciar), primero escriba en doublewrite (antes de MySQL 8.0.20, doublewrite se encuentra en el espacio de tabla compartido ibdata1. A partir de la versión 8.0.20, utiliza almacenamiento de archivos independiente y admite múltiples Archivos, pero el número máximo de archivos es el doble que el de la instancia del grupo de búfer, es decir, cada instancia del grupo de búfer tiene 2 archivos de escritura doble), cada vez que se escribe 1 MB de forma continua, y se escribe en la página de datos después de que la escritura doble se realiza correctamente, se escribe la página de datos De esta manera, si un accidente ocasiona que la página de datos se dañe, durante el Crash Recovery de la base de datos, intentará encontrar la página dañada de la doble escritura para sobrescribirla y repararla. Después de la reparación, el servidor MySQL se puede iniciar normalmente (Nota : Aunque Redo puede admitir la recuperación de datos, registra el contenido de modificación incremental de la página de datos, no la página de datos completa, pero la página de datos en doublewrite está completa, por lo que puede usar la página de datos completa en doublewrite Restaure la página de datos dañada y luego puede aplicar Rehacer normalmente)
* Doublewrite se divide en dos partes. Hay un búfer de doble escritura de 2 M en la memoria, y también hay dos espacios de escritura doble continuos de 1 M en el archivo de disco. El diagrama simple de escritura de datos después de la introducción de doublewrite es el siguiente. En la figura, podemos ver que los datos sucios deben tener éxito Para escribir en el archivo de datos, debe escribir en el disco dos veces (una vez para escribir dos veces y una vez en el archivo de datos)
El almacenamiento informático admite la escritura atómica ¿Cuáles son los beneficios para la base de datos?
* Dado que el almacenamiento admite escrituras atómicas a nivel de hardware, es decir, la función de escritura doble en el nivel de la base de datos se puede desactivar. Después de apagar, los datos sucios escritos en el archivo de datos solo necesitan escribirse en el disco una vez, lo que ahorra la mitad El flujo sucio del cepillo. Es decir, en el caso de garantizar que la página de datos no se escriba parcialmente, ¡puede aliviar directamente la necesidad urgente de un rendimiento de almacenamiento insuficiente!
La segunda característica importante: compresión / descompresión de datos transparente
¿Por qué es necesario comprimir / descomprimir la base de datos?
* En pocas palabras, después de que la cantidad de datos alcanza un cierto nivel, el costo de almacenamiento se ahorra en gran medida y el TCO de almacenamiento se reduce
¿Qué es la compresión / descompresión transparente de datos? Podemos comenzar a comprender desde la perspectiva de varios métodos de compresión / descompresión convencionales actuales
* Compresión / descompresión suave (es decir, compresión de CPU): como se muestra en la figura siguiente, al depender de la CPU del host para realizar operaciones de compresión y descompresión, hay una gran cantidad de replicación de datos y el enlace de replicación es largo, y la lógica de operación de compresión y descompresión debe ser implementada y controlada por el programa de aplicación.
* Compresión / descompresión de hardware (tarjeta de compresión): como se muestra en la figura siguiente, las operaciones de compresión y descompresión se realizan mediante una tarjeta de compresión dedicada que ocupa una ranura PCI. Aunque se liberan los recursos de la CPU del host, aún se requiere una gran cantidad de copias entre la memoria del host y la tarjeta de compresión Datos, ocupan muchos recursos de ancho de banda del host
* Compresión / descompresión transparente: como se muestra en la figura siguiente, el trabajo de cálculo de la compresión / descompresión se realiza directamente por la unidad informática integrada en la tarjeta de memoria, que es completamente transparente para la aplicación. La compresión y descompresión de datos se realizan íntegramente en el disco, liberando los recursos de la CPU del host. Al mismo tiempo, los recursos de ancho de banda del host también se liberan y no hay necesidad de copiar una gran cantidad de datos entre la memoria del host y la tarjeta de compresión (copia cero). Además, cuando se expande la tarjeta de memoria, la unidad de computación de compresión / descompresión se puede expandir al mismo tiempo, lo que puede realizar operaciones paralelas Operación de compresión / descompresión
El almacenamiento informático admite una compresión / descompresión transparente ¿Cuáles son los beneficios para la base de datos?
* Bajo la premisa de ser transparente a la aplicación y no ocupar ningún recurso del host, reduciendo considerablemente los costos de almacenamiento
* En la unidad de almacenamiento de la tarjeta de memoria, los datos almacenados se comprimen. Por lo tanto, la cantidad de datos almacenados se reduce enormemente. Para los componentes de almacenamiento de estado sólido, significa que la amplificación de escritura se puede reducir en gran medida y la reducción de la amplificación de escritura puede Deje que los componentes de almacenamiento de estado sólido maximicen sus ventajas de rendimiento y reduzcan la demora en la respuesta de E / S. Por lo tanto, para las bases de datos, cuando se implementa la compresión de datos, el rendimiento no puede verse afectado, o incluso se puede mejorar el rendimiento (especialmente la base de datos MySQL, después de que el volumen de datos alcanza un cierto tamaño, a medida que aumenta la relación de compresión, use Compresión transparente del almacenamiento informático + escritura doble cercana, el rendimiento incluso se puede mejorar considerablemente en algunos escenarios)
* Debido a que la función de compresión reduce el espacio físico ocupado por binlog, también reduce la frecuencia de limpieza de binlog debido a espacio de almacenamiento insuficiente. Al mismo tiempo, porque la función de compresión / descompresión se realiza en el disco (al escribir datos, primero la realiza el elemento de cálculo en el disco. Comprimido y luego almacenado en la unidad de almacenamiento; leer primero desde la unidad de almacenamiento y luego descomprimido por la unidad de computación en el disco), lo que reduce aún más la ocupación de ancho de banda del dispositivo de almacenamiento
* El Buffer Pool de InnoDB se utiliza principalmente para reducir las operaciones de E / S. La reducción en los retrasos de respuesta de IO de lectura y escritura significa que la dependencia de la memoria del host también se reduce. En otras palabras, el Buffer Pool de InnoDB se puede configurar más pequeño y En otras palabras, los recursos de memoria del host se pueden liberar y utilizar más para procesar las solicitudes de conexión del usuario.
La tercera característica importante: empujar el cálculo hacia abajo al almacenamiento (por supuesto, la lógica de cálculo que necesita ser empujada hacia abajo para diferentes negocios puede ser diferente, por lo tanto, empujar hacia abajo una lógica de cálculo poco común puede requerir investigación y desarrollo conjuntos)
¿Por qué la base de datos necesita transferir los cálculos al almacenamiento?
* Los tipos de consulta reales en el entorno de producción, las consultas no equivalentes (como: consulta de índice no única, consulta de tabla de unión, etc.) a menudo representan una proporción relativamente alta, y estas consultas (especialmente cuando las condiciones de consulta involucran múltiples columnas) no son similares a MySQL Con el soporte de la función ICP, la cantidad de datos leídos del motor de almacenamiento a menudo excede la cantidad de datos que realmente necesitan (por ejemplo: los datos que cumplen con todas las condiciones de consulta pueden tener solo 10 filas, pero la cantidad de datos realmente leídos desde el motor de almacenamiento Son 100 filas), esto se debe a que cuando MySQL ejecuta una consulta, seleccionará una columna de condición para recuperar datos en el motor de almacenamiento, devolverá los datos recuperados a MySQL Server y luego usará las columnas de condición restantes para filtrar los datos. Los datos que cumplen con todas las condiciones se devuelven al cliente. En este proceso, los datos filtrados son en realidad un desperdicio. Si usa características similares a MySQL ICP, puede enviar todas las columnas de condición a la capa del motor de almacenamiento y devolver directamente los datos que cumplen con todas las columnas de condición. No es necesario leer datos que no cumplan con todas las condiciones.
* Aunque las características de MySQL ICP pueden evitar la lectura de datos innecesarios del motor de almacenamiento, el cálculo de filtrado de la capa del motor de almacenamiento aún necesita consumir recursos de la CPU del host. ¿Se puede reducir aún más la cantidad de cálculo al dispositivo de almacenamiento? ¡poder!
¿Qué es la transferencia informática al almacenamiento? Las siguientes tres figuras explican brevemente la lógica de implementación de la computación push-down al almacenamiento
* Suponiendo una consulta con múltiples columnas condicionales (Nota: se asume que múltiples columnas condicionales son columnas de índice, por lo que no las repetiré a continuación). Sin el soporte de las características de MySQL ICP, el proceso de ejecución de la consulta es aproximadamente el siguiente (Nota Fuente roja, no entre en detalles a continuación). Suponiendo que la consulta puede utilizar un índice de varias columnas, la primera columna de la secuencia del índice se utilizará para la recuperación de datos (columna de recuperación), los datos se obtendrán del motor de almacenamiento y, a continuación, las columnas condicionales restantes (columnas de filtrado) se utilizarán en la capa del servidor MySQL. Filtra los datos que cumplen con todas las condiciones
* Si la consulta anterior es compatible con características similares a MySQL ICP, entonces la consulta puede evitar leer datos que no cumplan con todas las condiciones del motor de almacenamiento. Como se muestra en la figura siguiente, se descargan todas las columnas de condición (deben ser columnas de índice) Empuje a la capa del motor de almacenamiento, solo lea los datos que coincidan con todas las columnas condicionales, no es necesario realizar un filtrado de datos en la capa del servidor MySQL
* Llevar el cálculo al dispositivo de almacenamiento se refiere a una mayor optimización de las características similares a MySQL ICP, empujar la lógica de cálculo al dispositivo de almacenamiento y liberar aún más los recursos de la CPU del host y los recursos de ancho de banda del host, como se muestra en la siguiente figura
La compatibilidad con el almacenamiento informático traslada los cálculos a los dispositivos de almacenamiento. ¿Cuáles son los beneficios para la base de datos?
* A través de la introducción anterior, creo que es innecesario decir cuáles son los beneficios de enviar cálculos como MySQL ICP a los dispositivos de almacenamiento. Si se puede enviar más lógica de computación al dispositivo de almacenamiento, inevitablemente se liberará aún más la CPU, el ancho de banda e incluso los recursos de memoria del host, de modo que los recursos del host se puedan usar más para aceptar y procesar las solicitudes comerciales de los usuarios. ¡Mejore aún más el rendimiento de la base de datos!
3. Perspectivas futuras del almacenamiento informático
Las numerosas y excelentes características de la computación y el almacenamiento hacen posible aliviar y resolver sistemáticamente los cuellos de botella y los puntos débiles de varias bases de datos a la vez, en lugar del método tradicional, que requiere mucho tiempo, es laborioso y costoso, y a menudo pierde el otro.
Aunque todos los caminos conducen a Roma, no hay problemas técnicos que no se puedan resolver. Sin almacenamiento informático, ciertamente hay otras soluciones diversas, pero también necesitamos ver cómo se resuelve. Si hay un camino más cercano, ¿Por qué quieres estar lejos?
Personalmente, piense que el almacenamiento informático es una dirección de desarrollo con visión de futuro en el campo de las bases de datos. Por supuesto, eso no significa que pueda usar el almacenamiento informático de una vez por todas, pero al menos, cuando su volumen de datos no llega al punto en que el almacenamiento informático no puede soportarlo, puede más Evite o retrase algunos de los cuellos de botella y puntos débiles mencionados anteriormente. Además, hay otro punto importante: puede que no sea doloroso reducir el costo total de propiedad de un solo servidor, pero si su servidor es de gran escala, ¡los ahorros de costos no pueden subestimarse!
En cuanto al futuro, en qué tipo de almacenamiento informático se puede convertir, Dios lo sabe, pero creo que los avances técnicos de la capa inferior se pueden utilizar, es más rentable que algunas transformaciones técnicas que son difíciles de usar en la capa de aplicación. Por lo tanto, creo que mientras haya una fuerte demanda ¡Debe haber un hombre valiente que continuará logrando avances!
PD: El contenido anterior se basa en algunos artículos publicados (consulte el enlace al final del artículo para obtener más detalles). Los lectores que necesiten saber más, consulte el enlace de referencia al final del artículo, que incluye descripciones más detalladas y rendimiento completo Pruebe los datos, ¡espero que este artículo pueda ser más o menos útil para usted en su viaje a la base de datos!
4. Enlace de referencia
La introducción de ScaleFlux CSD 2000 (un producto de almacenamiento informático de alto rendimiento de ScaleFlux) en el blog de Percona: https://www.percona.com/blog/2020/08/06/how-can-scaleflux-handle-mysql- Carga de trabajo / Informe técnico (que incluye más datos y conclusiones de pruebas de CSD 2000): https://learn.percona.com/hubfs/Collateral/Whitepapers/Testing-the-Value-of-ScaleFlux.pdf
"Traducción | MySQL basado en la prueba de rendimiento SSD de ScaleFlux" en la cuenta pública de WeChat "yangyidba": https://mp.weixin.qq.com/s/MNBNKlxiBBXGSOyzm5HGdQ
"Almacenamiento computable: compresión de datos y pushdown de cálculo de base de datos" en la cuenta pública de WeChat "Laoye Teahouse": https://mp.weixin.qq.com/s/iAg64XNrrZxRCLdlRJjFCQ
"Almacenamiento computable: compresión transparente, modelo de E / S de base de datos y vida útil de SSD" en la cuenta pública de WeChat "ScaleFlux": https://mp.weixin.qq.com/s/jh4JzyXSGhxldT01paCPvw
"¡Demasiado potente! NVMe SSD convertido en memoria" en la cuenta pública de WeChat "SSDFans": https://mp.weixin.qq.com/s/niZmq170l4HDnfyw0rmRFg
Introducción a la realización de escritura atómica automática en MariaDB: https://mariadb.com/kb/en/atomic-write-support/
-
https://mariadb.com/kb/en/mariadb-1055-changelog/
Sobre el Autor:
Luo Xiaobo @ ScaleFlux, uno de los autores de "A Thousand Golden Recipes-MySQL Performance Optimization Pyramid".
Familiarizado con la arquitectura MySQL, bueno en el ajuste general de bases de datos, me gusta especializarse en tecnología de código abierto y interesado en la promoción de la tecnología de código abierto, ha compartido muchos temas de bases de datos públicas en línea y fuera de línea, y ha publicado casi 100 artículos de investigación relacionados con bases de datos.
El texto completo ha terminado.
La clase "MySQL Core Optimization" de Teacher Ye se ha actualizado a MySQL 8.0, escanee el código para comenzar el viaje de la práctica de MySQL 8.0