El autor de este artículo es Feng Ke, arquitecto jefe de Huawei Cloud Database GaussDB
introducción de fondo
La combinación de compresión de datos y bases de datos relacionales ya no es un tema nuevo, hemos visto varios productos y soluciones de compresión de bases de datos. Para GaussDB, la introducción de la compresión de datos en la actualidad y qué valor diferente puede aportar a los clientes es una pregunta en la que hemos estado pensando durante algún tiempo en el pasado.
Para responder a esta pregunta, primero realizamos pruebas exhaustivas en varios algoritmos de compresión comunes, desde LZ4/Snappy con el mejor rendimiento, hasta Zstd/Zlib con un rendimiento y una relación de compresión equilibrados, hasta LZMA/BZip con énfasis en la relación de compresión. Descubrimos que incluso los mejores algoritmos de compresión no pueden hacerlo sin afectar significativamente el rendimiento de una base de datos en línea. También hemos investigado varios métodos de codificación en el campo de las bases de datos, incluidos algunos métodos de codificación basados en la predicción y el ajuste lineal publicados por la comunidad académica en los últimos años. A partir de los resultados de las pruebas y las mediciones reales publicadas por la investigación, la codificación de la base de datos se utiliza para resolver problemas específicos. distribuciones numéricas En comparación con la madurez del algoritmo de compresión, actualmente no existe un método de codificación de base de datos general que pueda proporcionar una tasa de compresión estable en la mayoría de los escenarios en conjuntos de datos reales.
Este es nuestro criterio técnico básico en el campo de la compresión de bases de datos. La práctica anterior del producto también ha verificado este punto. Hemos visto que muchas bases de datos comerciales y bases de datos de código abierto brindan soporte para la compresión. La mayoría de las veces, la elección que se deja a los clientes es decidir si habilitar la compresión en una tabla específica. Activar la compresión significa ahorrar espacio, pero al mismo tiempo significa degradar el rendimiento. Esta elección aparentemente simple es precisamente la más difícil de hacer para los clientes. Esta es la razón por la que hay tantos productos de compresión de bases de datos, pero rara vez vemos la razón fundamental por la que la compresión de datos se usa mucho en los negocios de bases de datos en línea.
Esto nos da más inspiración. Creemos que la tecnología de compresión de bases de datos verdaderamente aplicable, que puede equilibrar la relación de compresión y el impacto comercial, debe ser selectiva. Es decir, podemos determinar la temperatura de los datos en función de la tecnología y, en función de esta determinación, podemos comprimir selectivamente datos relativamente fríos en el negocio sin tocar esos datos relativamente calientes.
Tal elección técnica significa que no podemos satisfacer todos los escenarios comerciales. Requerimos que la distribución de temperatura de datos del negocio cumpla con la regla de distribución 80-20. Es decir, comprimimos los datos fríos que ocupan el 80 % de los requisitos de almacenamiento pero solo el 20 % de los requisitos informáticos, y no tocamos los datos calientes que solo ocupan el 20 % de los requisitos de almacenamiento pero ocupan el 80 % de los requisitos informáticos. Afortunadamente, encontramos que la mayoría de los negocios que requieren control de capacidad tienen tales características.
Selección de escenarios y objetivos
A través del análisis de una gran cantidad de escenarios comerciales, encontramos que las necesidades comerciales de la tecnología de compresión de bases de datos están diversificadas. Hay escenarios de compresión de almacenamiento de negocios de transacciones en línea (OLTP), escenarios de compresión de almacenamiento de negocios de análisis (OLAP) y escenarios de compresión de almacenamiento de negocios históricos. También hay escenarios en los que se comprime la transmisión empresarial de recuperación ante desastres. En diferentes escenarios, los requisitos para la tecnología de compresión son completamente diferentes en términos de indicadores tridimensionales de rendimiento de compresión, tasa de compresión y rendimiento de descompresión, y en términos de tolerancia a la intrusión comercial.
Esto significa que si queremos crear una función de compresión avanzada de escenario completo de GaussDB, debe ser una combinación de múltiples tecnologías, incluidos diferentes algoritmos de compresión, diferentes modelos y métodos de juicio en caliente y en frío, diferentes organizaciones de almacenamiento de datos, etc., a través de diferentes Combinación de tecnologías y aplicaciones para satisfacer las necesidades de diferentes escenarios.
Esto también significa que debemos tener una compensación prioritaria en el soporte de diferentes escenarios de aplicaciones de compresión. Nuestra respuesta es optar por dar prioridad al soporte de escenarios de compresión de almacenamiento OLTP, esta es el área comercial donde creemos que la tecnología de compresión de bases de datos es más valiosa y, por supuesto, también es el área con mayores desafíos técnicos.
Después de determinar el escenario, el siguiente paso es determinar el objetivo técnico.Qué tipo de competitividad central queremos construir para este escenario depende de nuestro análisis de los escenarios típicos de los clientes. Identificamos dos escenarios típicos de clientes:
Escenario A: El negocio del cliente proviene de una minicomputadora IBM con una capacidad de base de datos única de 50 TB, luego de migrar a la plataforma abierta enfrenta los problemas de capacidad excesiva y ventanas largas de operación y mantenimiento. Elegir desensamblar la base de datos significa una transformación distribuida.Para un negocio clave existente que ha estado funcionando de manera estable durante muchos años, el riesgo de elegir esta tecnología es demasiado alto. La elección de la compresión puede reducir significativamente los riesgos de capacidad, pero el diseño inicial del negocio no consideró la separación de calor y frío (como establecer particiones basadas en la dimensión temporal). Se requiere un soporte de tecnología de compresión cero intrusiva, y el impacto el rendimiento empresarial es lo suficientemente bajo.
Escenario B: el negocio del cliente se implementa en base a clústeres distribuidos. La capacidad de un solo clúster ha superado 1 PB y sigue creciendo rápidamente, lo que requiere una expansión periódica. La elección de la compresión puede reducir la frecuencia de expansión de la capacidad, reducir significativamente los costos de software y hardware empresarial y reducir el riesgo de cambio. Sin embargo, el diseño de distribución de datos del negocio está orientado a la escalabilidad (como la creación de particiones basadas en la dimensión del usuario), sin considerar la separación de frío y calor, por lo que el negocio también necesita un soporte de tecnología de compresión cero intrusiva con suficiente bajo impacto en el rendimiento.
Mediante la clasificación de los requisitos de los escenarios típicos de los clientes, determinamos los objetivos de diseño básicos de la compresión de almacenamiento OLTP de GaussDB:
-
El juicio caliente y frío debe ser cero intrusivo para el negocio, y no debe depender de la distribución de datos existente y el modelo lógico del negocio;
-
El impacto en el negocio debe ser lo suficientemente bajo, definimos el objetivo en menos del 10% y el desafío del 5%;
-
Para proporcionar una relación de compresión razonable, definimos el objetivo para que no sea inferior a 2:1.
La definición de objetivos básicos de diseño nos permite convertir la posterior selección de tecnología en cada escenario específico en un problema determinista.
Juicio frío y caliente
Después de determinar los objetivos de diseño, comenzamos a implementar el proyecto. Hay tres problemas a resolver: 1) Cómo realizar la determinación de datos calientes y fríos; 2) Cómo realizar la organización del almacenamiento de datos comprimidos; 3) Cómo realizar un algoritmo de compresión competitivo.
Para juicios calientes y fríos, primero se debe determinar la granularidad del juicio. El juicio caliente y frío de los datos se puede implementar en función de diferentes granularidades, como nivel de fila, nivel de bloque o nivel de tabla/partición. Cuanto más gruesa sea la granularidad, menor será la complejidad de la implementación, pero mayor será la intrusión en el negocio. Con base en los objetivos de diseño, es natural que elijamos el juicio de frío y calor a nivel de fila, que es la solución con la menor dependencia de la distribución de datos comerciales. Lo que necesitamos resolver es cómo controlar el costo de introducir frío y calor. juicio.
Resolvimos inteligentemente este problema utilizando el mecanismo existente del motor de almacenamiento GaussDB. Específicamente, el motor de almacenamiento de GaussDB registra el ID de transacción (XID) de la última modificación de la fila en los metadatos Meta de cada fila de datos Esta información se utiliza para respaldar el juicio de visibilidad de la transacción, implementando así el control de concurrencia de múltiples versiones. (MVCC). Para una fila específica, si su XID es lo suficientemente "antiguo" como para que sea visible para todas las transacciones actualmente activas, entonces en realidad no nos importa el valor específico del XID en este momento. Podemos introducir una bandera específica (FLG) para registrar esto, y el valor rellenado en el XID original puede ser reemplazado por una hora física, que representa el límite superior de la última hora de modificación (LMT, Last Modified Time) de la fila a la que pertenece. Obviamente, LMT se puede utilizar para respaldar juicios calientes y fríos (consulte la Figura 1 para obtener más detalles):
Figura 1: Determinación de frío y calor a nivel de fila
DESPUÉS DE 3 MESES SIN MODIFICACIÓN
En este momento, el sistema escanea la tabla de destino y comprime todas las filas que cumplen con el tiempo actual menos el LMT durante más de 3 meses.
Tenga en cuenta que en el esquema anterior, en realidad solo identificamos los puntos de acceso de escritura de las filas, pero no identificamos los puntos de acceso de lectura de las filas. Solo sabemos que las filas que cumplen las condiciones no se han actualizado dentro de los 3 meses, pero no podemos confirme que estas filas son en meses 3. Si se lee con frecuencia dentro de un mes. Actualmente, no existe una solución técnica de bajo costo para mantener los puntos de acceso de lectura de las filas. Para los servicios de canalización, como los detalles de pedidos, esta solución funciona bien, porque la lectura y escritura de datos exhiben las mismas características de temperatura, y su frecuencia de acceso continúa disminuyendo a medida que aumenta el tiempo sin modificar. Sin embargo, para los servicios de recopilación, como los álbumes de fotos de teléfonos móviles, puede que no sea suficiente identificar y escribir únicamente, porque aún se puede acceder con frecuencia a una relación de recopilación establecida muy temprano.
Esto significa que, incluso si el sistema hace juicios calientes y fríos, todavía tenemos que optimizar los escenarios en los que la empresa puede acceder a los datos comprimidos. Dejamos este problema a la organización del almacenamiento y al algoritmo de compresión. Para el algoritmo de compresión, prestamos más atención a su rendimiento de descompresión.
Otro problema es que, en algunos escenarios, puede que no sea suficiente usar el juicio caliente y frío predeterminado. Por ejemplo, para algunos tipos de transacciones, es posible que los detalles de la orden generada no se modifiquen dentro de los 3 meses, pero se actualizarán después de cierto tiempo. se cumple la condición de activación (como descongelar transacciones garantizadas). Este escenario no es común en el negocio real, pero si el negocio realmente se preocupa por el rendimiento, entonces admitimos permitir que el negocio personalice las reglas además de las reglas predeterminadas de juicio caliente y frío, como:
DESPUÉS DE 3 MESES SIN MODIFICACIÓN EN (order_status = “terminado”)
En este momento, el sistema solo comprimirá los datos que no hayan sido modificados durante 3 meses y cuyo estado de pedido haya sido completado.
Actualmente, las reglas personalizadas que admitimos son cualquier expresión de fila legal. La empresa puede escribir cualquier expresión compleja para representar las reglas de juicio caliente y frío de los datos, pero los campos a los que se hace referencia en las expresiones solo pueden ser los campos de la tabla de destino. legal campos. A través de esta combinación de reglas predeterminadas y personalizadas, brindamos a las empresas un umbral de uso lo suficientemente bajo y una mayor flexibilidad.
organización de almacenamiento
Cuando se comprimen las filas que cumplen con las condiciones de juicio caliente y frío, debemos decidir cómo almacenar los datos comprimidos Basándonos en el objetivo de diseño, elegimos la implementación de la organización de almacenamiento con la menor intrusión comercial: compresión intrabloque.
Sabemos que la organización del almacenamiento de las bases de datos relacionales se basa en bloques de longitud fija. En la base de datos GaussDB, el tamaño típico del bloque de datos es de 8 KB. Elegir un bloque de datos más grande es obviamente beneficioso para la compresión, pero causará un mayor impacto en el rendimiento del negocio. .Influencia. La llamada compresión intra-bloque se refiere a: 1) Todas las filas en un solo bloque que cumplan con las condiciones de juicio caliente y frío se comprimirán como un todo; 2) Los datos formados después de la compresión se almacenan en el bloque de datos actual, y el área de almacenamiento se llama BCA (Block Compressed Area), que generalmente se encuentra al final del bloque.
El diseño de compresión intrabloque significa que la descompresión de cualquier dato solo depende del bloque actual, sin acceder a otros bloques de datos.Desde la perspectiva de la relación de compresión, este diseño no es el más amigable, pero es muy beneficioso para controlar el impacto comercial. Tenga en cuenta que en nuestra discusión anterior, incluso si el negocio define condiciones de juicio calientes y frías, todavía hay una cierta probabilidad de que se acceda a los datos comprimidos. Esperamos que este costo de acceso pueda tener un límite superior determinista.
La Figura 2 muestra el proceso detallado de la compresión intrabloque: primero, cuando se activa la compresión, el sistema escanea todas las filas en el bloque de datos y reconoce que R1 y R3 son datos fríos de acuerdo con las condiciones de juicio calientes y frías especificadas ( Figura 2(a)); luego, el sistema comprime R1 y R3 como un todo, y almacena los datos comprimidos en el BCA del bloque de datos (Figura 2(b)); si la empresa necesita actualizar R1 más tarde, el sistema actualizará Los últimos datos generan una nueva copia R4 y marcan que R1 en el BCA ha sido eliminado (como se muestra en la Figura 2©); finalmente, cuando el sistema necesita más espacio en el bloque de datos, puede reclamar el espacio que pertenece a R1 en el BCA (Figura 2(d)).
Figura 2: Compresión intrabloque
algoritmo de compresión
Según los objetivos de diseño, si observamos los indicadores tridimensionales de la relación de compresión, el rendimiento de compresión y el rendimiento de descompresión, lo que realmente necesitamos es un algoritmo de compresión que pueda proporcionar una relación de compresión razonable, un rendimiento de compresión razonable y un rendimiento de descompresión final. Esta es la base de nuestro diseño de algoritmo de compresión.
Primero probamos el uso directo de LZ4 para la compresión. LZ4 se conoce actualmente como una biblioteca tripartita de código abierto con el mejor rendimiento de compresión y descompresión. A partir de los resultados de las mediciones reales, la tasa de compresión de LZ4 es relativamente baja. Analizamos cuidadosamente el principio de su algoritmo. LZ4 es una implementación basada en el algoritmo LZ77. La idea del algoritmo LZ77 es muy simple, es decir, los datos a comprimir se consideran un flujo de bytes. El algoritmo comienza desde el actual posición del flujo de bytes y adelante.Encuentre la cadena coincidente que es la misma que la posición actual, y luego use la longitud de la cadena coincidente y el desplazamiento desde la posición actual para representar la cadena coincidente, a fin de lograr el efecto de compresión. Desde la perspectiva del principio del algoritmo, el algoritmo LZ77 tiene un mejor efecto de compresión para texto largo, pero para una gran cantidad de texto corto y tipos numéricos en datos estructurados, el efecto es limitado. Nuestras pruebas reales también han verificado este punto.
A continuación, dividimos el algoritmo de compresión en dos capas: en la primera capa, codificamos algunos tipos numéricos por columnas, y elegimos la codificación de diferencia simple, que es lo suficientemente liviana para descomprimir campos específicos sin depender de los valores de otros campos; en la segunda capa, la llamamos LZ4 para comprimir los datos codificados. Tenga en cuenta que en la primera capa, en realidad codificamos por columna y almacenamos por fila, lo cual es muy diferente de la implementación general en la industria (codificar y almacenar por columna). El almacenamiento por columna será más amigable con la tasa de compresión, pero la columna por almacenamiento en columna significa que los datos de una misma fila estarán dispersos a diferentes áreas del BCA.Este diseño tradicional no puede soportar la descompresión parcial que esperamos lograr más adelante.Explicaremos este problema con más detalle en la conclusión.
A través de la medición real, encontramos que esta implementación de codificación de columnas + compresión general mejora efectivamente la tasa de compresión y al mismo tiempo controla el aumento obvio en el impacto comercial, pero la implementación de dos capas está débilmente acoplada, lo que introduce muchos gastos adicionales. . Por lo tanto, después de un cuidadoso análisis, decidimos abandonar LZ4 y volver a implementar un algoritmo de compresión fuertemente acoplado basado completamente en el algoritmo LZ77.
Esto parecía ser un intento muy arriesgado en ese momento. De hecho, antes que nosotros, ningún equipo de kernel de base de datos elegiría implementar un algoritmo de compresión general por sí mismo. Pero a juzgar por los beneficios finales, en realidad abrimos una puerta completamente nueva. Cuando se rompe el límite entre la codificación de columnas y el algoritmo LZ77, presentamos una serie de innovaciones de optimización. Teniendo en cuenta el espacio, no podemos mostrar todos los detalles técnicos. Aquí, solo presentamos dos pequeñas optimizaciones:
La primera optimización son los límites de fila integrados. Descubrimos que cuando el sistema adopta el algoritmo de compresión de dos capas, necesitamos guardar adicionalmente la longitud codificada de cada fila de datos, porque necesitamos encontrar el límite de cada fila después de descomprimir el algoritmo LZ77, que no es un pequeño gastos generales. Para eliminar esta sobrecarga, elegimos incrustar una marca de límite de línea en el formato de codificación LZ77. Esta marca solo ocupa 1 bit y su sobrecarga se reduce considerablemente en comparación con el esquema existente. Por supuesto, con este bit de marcador ocupado, la longitud máxima de la ventana de la búsqueda directa LZ77 se reduce a la mitad, pero en nuestro escenario, esto no es un problema, porque nuestra longitud típica de página es de solo 8 KB.
La segunda optimización es la codificación corta de 2 bytes. En la implementación original de LZ4, para mejorar el rendimiento de la compresión, el sistema usa una codificación de 3 bytes para describir una coincidencia, lo que significa que la coincidencia más corta que el sistema puede identificar es de 4 bytes. Pero en datos estructurados, la coincidencia de 3 bytes es muy común, consulte el siguiente ejemplo:
A = 1 … B = 2
Entre ellos, A y B son dos campos enteros en la misma fila de datos, y sus valores son respectivamente 1 y 2. Según el orden de bytes actual, la forma de almacenamiento real de la fila de datos en la memoria es la siguiente:
01 00 00 00 … 02 00 00 00
Preste atención a la parte marcada en rojo arriba. Obviamente, hay una coincidencia de 3 bytes, pero LZ4 no puede reconocerla.
Resolvemos este problema introduciendo un código corto adicional de 2 bytes en el algoritmo LZ77. El código corto de 2 bytes puede identificar una coincidencia mínima de 3 bytes, mejorando así la tasa de compresión en comparación con LZ4.
Por supuesto, la introducción de códigos cortos tendrá una sobrecarga adicional: primero, el rendimiento de compresión disminuirá hasta cierto punto, porque necesitamos establecer dos tablas HASH independientes. Afortunadamente, en nuestro escenario, el rendimiento final de compresión no es nuestro objetivo. segundo, la codificación de 2 bytes reduce el ancho de bits que expresa la distancia entre la cadena coincidente y la cadena coincidente, lo que significa que la coincidencia de 3 bytes debe estar más cerca para ser reconocida. problema, porque la longitud de una fila de datos típica es lo suficientemente pequeña en relación con este límite.
evaluación del efecto
Usamos pruebas estándar de TPCC para evaluar el impacto comercial de habilitar la función de compresión de almacenamiento OLTP. El modelo TPCC contiene un total de 9 tablas, de las cuales hay 3 tablas de flujo cuyo espacio crecerá dinámicamente. Entre estas 3 tablas, la tabla de detalles de pedidos (tabla de línea de pedidos) tiene un orden de magnitud de crecimiento de espacio mayor que otras tablas, por lo que elija usar esta tabla Active la compresión. En base a la semántica de negocio de TPCC, una vez completada la entrega de cada pedido, el estado del pedido pasará a estado completado, el pedido completado no será modificado, pero aún existe cierta probabilidad de que sea consultado. Con base en esta semántica, elegimos el principio de juicio caliente y frío para comprimir solo las órdenes completadas.
Probamos los valores de rendimiento del sistema sin compresión y con compresión, y los resultados se muestran en la Figura 3:
Figura 3: Evaluación de impacto comercial
Probamos la tasa de compresión de la tabla Orderline.Como un conjunto de datos más rico, también seleccionamos cuatro tablas (Lineitem, Orders, Customer y Part tables) en el modelo TPCH para probar. A modo de comparación, para cada conjunto de datos, probamos el rendimiento de la tasa de compresión de LZ4, ZLIB y nuestro algoritmo de compresión al mismo tiempo Entre ellos, ZLIB es un algoritmo que enfatiza el rendimiento de compresión y descompresión y el equilibrio de la tasa de compresión, y su compresión y descompresión el rendimiento es 5 veces menor que el de LZ4.-10 veces. El resultado final se muestra en la Figura 4:
Figura 4: Evaluación de la relación de compresión
Consejos de operación y mantenimiento
Tenga en cuenta que nuestro esquema de compresión en realidad está fuera de línea, es decir, cuando los datos se generan por primera vez, deben ser datos calientes, no activarán la compresión y el rendimiento del acceso comercial a estos datos no se verá afectado de ninguna manera; a medida que pasa el tiempo por, el rendimiento de estos datos La temperatura disminuirá gradualmente y eventualmente será reconocido como datos fríos por tareas de compresión independientes y comprimidos.
La elección de ejecutar estas tareas de compresión durante las horas laborales de menor demanda y el control de su consumo de recursos son cuestiones a las que se debe prestar atención por parte de la operación y el mantenimiento. En esta área, proporcionamos una gran cantidad de métodos de operación y mantenimiento, incluida la especificación de la ventana de operación y mantenimiento, el paralelismo de las tareas de compresión y la cantidad de datos comprimidos para cada tarea de compresión. Para la mayoría de las empresas, la cantidad de datos recién agregados por unidad de tiempo en realidad es relativamente limitada, por lo que la empresa también puede elegir un período de tiempo específico para completar la tarea de compresión de forma intensiva, como de 2:00 a. m. a 4:00 a. m. el primer día. día de cada mes punto, complete la compresión de datos fríos agregados hace 3 meses.
Antes de que una empresa decida habilitar la compresión, es posible que desee comprender los beneficios después de habilitar la compresión y tomar una decisión basada en el tamaño de los beneficios. Con este fin, proporcionamos una herramienta de evaluación de la tasa de compresión, que puede muestrear los datos de la tabla de destino y usar el mismo algoritmo que el proceso de compresión real para comprimir los datos muestreados y calcular la tasa de compresión, pero en realidad no generará BCA. y no modificará ningún dato.
Si la empresa migra datos comprimidos a otra tabla, todos los datos pueden cambiar de comprimidos a sin comprimir, lo que resulta en una expansión del espacio. Esto no se presenta en nuestra solución, sino que es un problema que todas las soluciones de compresión deben resolver. Si las reglas de juicio en caliente y en frío son muy seguras, la empresa puede ejecutar manualmente la tarea de compresión para que la compresión surta efecto de inmediato; para la migración de tablas comprimidas de gran capacidad que lleva mucho tiempo, la empresa aún puede optar por iniciar la tarea de compresión automática periódicamente para completar.
Por último, proporcionamos el control más detallado para habilitar y deshabilitar la compresión. Ya sea que se trate de una sola partición en una tabla común, una tabla de particiones comunes o cualquier partición o subpartición en una partición secundaria, el negocio se puede convertir activar o desactivar la compresión de forma independiente. Esto hace posible que, en escenarios en los que la propia empresa haya diferenciado datos calientes y fríos (por ejemplo, en función de la partición de tiempo), aún pueda funcionar bien con nuestra función de compresión.
conclusión
En la función de compresión de tablas OLTP, hemos introducido una serie de innovaciones tecnológicas, que incluyen algoritmos de compresión completamente nuevos, determinación automática de frío y calor de granularidad fina y soporte de compresión intrabloque, que puede reducir en gran medida el impacto en la tabla mientras proporcionando una tasa de compresión razonable Impacto comercial, esperamos que esta función pueda desempeñar un papel importante en el soporte del control de capacidad de los servicios en línea críticos.
A continuación, continuaremos innovando e iterando para reducir el impacto de la introducción de la compresión en el negocio, las funciones de descompresión parcial y la compresión del índice OLTP. Esperamos tener avances tecnológicos innovadores para resolver problemas relacionados y crear un mayor valor para el negocio.