Explicación detallada del rendimiento de Redo Log & CacheEngine

Este tutorial presenta Redo Log y CacheEngine en DolphinDB, su relación entre sí y su impacto en el rendimiento general.

Cabe señalar que solo funcionan en bases de datos DFS, no en tablas de disco y tablas de flujo. Además, después de habilitar Redo Log, CacheEngine debe estar habilitado.

1 registro de rehacer

1.1 ¿Qué es el registro de rehacer?

En los sistemas de bases de datos relacionales, el registro de escritura anticipada (WAL) es una serie de tecnologías que se utilizan para proporcionar atomicidad y durabilidad. El concepto de Redo Log en DolphinDB es similar al de WAL. En resumen, la idea central de Redo Log es modificar el archivo de la base de datos solo después de que el registro de registro que describe el cambio se actualice al almacenamiento persistente. Si sigue este proceso, no necesita vaciar las páginas de datos en el disco cada vez que realiza una transacción, porque cuando la base de datos deja de funcionar, puede usar el registro para restaurar la base de datos y todos los cambios que no se han aplicado. se puede rehacer desde los registros de registro.

La principal ventaja de usar Redo Log es que reduce en gran medida el número de escrituras en disco, porque cuando se confirma la transacción, solo el archivo de registro debe vaciarse en el disco, en lugar de vaciar todos los archivos involucrados en la transacción. Otra razón para usar Redo Log es que el rendimiento de escritura secuencial es mejor. Dado que cada columna de una tabla en DolphinDB se almacena como un archivo, esta diferencia es particularmente obvia cuando el número de columnas es particularmente grande.

Redo Log tiene dos mecanismos de reciclaje, uno es el reciclaje periódico y el otro es el reciclaje cuando el tamaño alcanza el límite Ambos métodos tienen parámetros correspondientes que se pueden configurar.

1.2 ¿Por qué necesita Redo Log?

La introducción de Redo Log es principalmente para resolver problemas de coherencia de datos en condiciones extremas, como cortes de energía y tiempo de inactividad del sistema de base de datos. Si no hay Redo Log, pero este problema aún no se ha resuelto, se debe llamar a fsync para vaciar todos los datos de la memoria en el disco después de enviar cada transacción, entonces el rendimiento de todo el sistema se reducirá drásticamente. Esto se debe a que el disco duro tiene un número muy limitado de fsyncs por segundo. Después de la introducción de Redo Log, solo necesita realizar fsync en archivos de registro individuales, y los archivos de datos se escriben de forma asincrónica, lo que favorece el rendimiento general de escritura. Redo Log se utiliza principalmente en escenarios donde la base de datos se escribe en tiempo real. Si solo se usa para el análisis de datos históricos, puede considerar no abrir Rehacer Log.

1.3 El impacto de Redo Log en el rendimiento

Redo Log aumentará la carga en el disco, porque el archivo de Redo Log se escribe además del archivo de datos; también aumentará el uso de memoria, porque el sistema almacena internamente en caché los archivos de datos que no se han escrito en el disco. Según los dos puntos anteriores, después de abrir Redo Log, la carga general del sistema aumentará y el rendimiento de escritura también disminuirá. La disminución está relacionada con los datos reales, generalmente alrededor del 20%. Además, el tiempo de inicio del sistema también puede aumentar, porque el registro de rehacer que quedó de la última vez debe rehacerse durante el inicio, y la base de datos DFS no está disponible durante el proceso de rehacer.

1.4 Introducción a los parámetros relacionados

Si está en modo de clúster, Redo Log solo debe configurarse en los nodos de datos, y Redo solo se usa para la parte de almacenamiento de datos de la base de datos, sin involucrar al nodo maestro. Debido a que solo los metadatos de la base de datos DFS se almacenan en el nodo principal, no tiene nada que ver con Redo Log.

dataSync: este parámetro controla si se usa la función Rehacer Registro. Un valor de 1 significa habilitar Rehacer Registro. El valor predeterminado es 0, lo que significa que la función no está habilitada.
redoLogDir: este parámetro controla la ubicación de almacenamiento de los archivos de Redo Log. Generalmente se recomienda establecer esta ubicación en ssd para obtener el mejor rendimiento. El valor predeterminado está en el directorio log / redoLog en homeDir (determinado por el parámetro de inicio). Si es un modo de clúster, tenga cuidado de configurar los directorios de diferentes nodos de datos por separado para evitar usar el mismo directorio, lo que puede causar errores de escritura.
redoLogPurgeLimit: este parámetro controla el espacio máximo ocupado por el archivo de registro de rehacer, la unidad es GB y el valor predeterminado es 4. Cuando el tamaño del archivo de registro de rehacer excede este valor, comenzará a reciclarse automáticamente.
redoLogPurgeInterval: Este parámetro controla el período de recuperación automática de Redo Log. La unidad es la segunda. El valor predeterminado es 30, lo que significa que se recupera automáticamente cada 30 segundos.

2 CacheEngine

2.1 ¿Qué es CacheEngine?

CacheEngine es un mecanismo de almacenamiento en caché de escritura de datos en DolphinDB. Se presenta para resolver el problema de una fuerte caída en el rendimiento de escritura cuando el número de columnas de la tabla de datos es demasiado grande. DolphinDB usa almacenamiento en columnas y cada columna de datos en una partición se almacena en un archivo por separado. Si hay demasiadas columnas en la tabla (por ejemplo, se registran miles de indicadores al mismo tiempo en el escenario de IoT), cada vez que se escriben datos, se deben operar miles de archivos físicos (abrir, escribir, cerrar, etc. ). Después de la introducción de CacheEngine, la operación de escritura se escribe primero en la caché y, una vez que se alcanza un cierto umbral, los datos de la caché se escriben en el disco de forma asincrónica.

La lógica básica de que CacheEngine puede mejorar el rendimiento de escritura es: al escribir un archivo, el tiempo para escribir 1 fila de datos es básicamente el mismo que para escribir 1000 filas de datos, y la mayor parte del tiempo se dedica a abrir y cerrar el archivo; por lo tanto, si almacena en caché varias escrituras pequeñas y lotes de escritura en una E / S de archivo, puede ahorrar mucho tiempo en la sobrecarga causada por la apertura y cierre de archivos, mejorando así el rendimiento de escritura general del sistema.

2.2 La relación entre CacheEngine y Redo Log

Al usar CacheEngine, para evitar la pérdida de datos en la caché debido a cortes de energía, tiempo de inactividad, etc., debe completarse con Redo Log. En este caso, la recolección de basura de Redo Log dependerá de la recolección de basura de CacheEngine. En resumen, para garantizar que los datos se puedan recuperar de Redo Log en casos extremos, Redo Log primero debe confirmar a CacheEngine que la transacción ya no está en la caché antes de reciclar el registro de una determinada transacción, es decir, ha sido reciclado por CacheEngine. Por lo tanto, tenga cuidado de no establecer el tamaño de la caché de CacheEngine demasiado grande, de lo contrario, las transacciones permanecerán en la caché durante mucho tiempo y Redo Log no las podrá reclamar, lo que hará que el espacio ocupado por Redo Log continúe creciendo. Si esto sucede, Redo Log puede llenar el espacio en disco y causar posteriores errores de escritura. También puede hacer que se rehaga una gran cantidad de transacciones cuando se restaura la base de datos, lo que resulta en un tiempo de reinicio prolongado.

2.3 El impacto de CacheEngine en el rendimiento

El uso de CacheEngine reducirá la carga del disco, porque el número de escrituras se reduce y una pequeña cantidad de escrituras múltiples se convierte en escrituras por lotes; aumentará el uso de memoria porque el sistema almacena en caché los datos que no se han escrito en el disco; El rendimiento de escritura del sistema se puede mejorar, especialmente cuando aumenta el número de columnas.

2.4 Introducción a los parámetros relacionados

chunkCacheEngineMemSize: este parámetro representa el tamaño máximo de datos retenidos de CacheEngine, la unidad es GB y el tipo es doble. El valor predeterminado es 0.0, lo que significa que CacheEngine no se utiliza. Si el valor es mayor que 0, cuando CacheEngine ocupe más del 30% del valor, iniciará activamente el reciclaje asincrónico. Además, la base de datos recolectará basura el CacheEngine una vez cada minuto.

2.5 Introducción a funciones relacionadas

purgeCacheEngine: Utilice esta función para vaciar manualmente la memoria caché. Debe tenerse en cuenta que solo se vaciarán las transacciones completadas y las transacciones que estén en curso pero que aún no se hayan confirmado no se vaciarán.
getCacheEngineStat: use esta función para ver el estado de CacheEngine.
getCacheEngineMemSize: use esta función para ver el tamaño de memoria que ha usado CacheEngine.

3 Precauciones y proceso de inicio del clúster DolphinDB

El proceso de inicio de un clúster de DolphinDB es generalmente el siguiente: primero, inicie el nodo maestro, luego inicie cada nodo de agente y finalmente inicie el nodo de datos.

Si el tiempo de inicio es demasiado largo, la posible razón es que quedan demasiados registros de rehacer después de que finaliza la última operación del clúster. Hay tres razones:

El espacio en disco configurado por Redo Log es demasiado grande, lo que hace que el archivo de Redo Log nunca se recupere.
El período de reciclaje configurado por Redo Log es demasiado largo y no se ha activado el reciclaje.
La memoria configurada por CacheEngine es demasiado grande, lo que hace que CacheEngine nunca se recicle, bloqueando el reciclaje del Redo Log.

Para evitar las situaciones anteriores, debe prestar atención a los tres parámetros de redoLogPurgeLimit, redoLogPurgeInterval y chunkCacheEngineMemSize en los parámetros del clúster.

Existe otra posibilidad de que los archivos de Redo Log se almacenen en el disco duro mecánico. Se necesita mucho tiempo para leer estos archivos cuando se inicia el clúster. Por lo tanto, se recomienda configurar redoLogDir en el ssd, que también puede acelerar el reinicio del clúster.

4 RaftLog

4.1 ¿Qué es balsa?

Raft es un protocolo que se utiliza para mantener la coherencia de varias copias en un sistema distribuido. En un clúster con una naturaleza consistente, todos los nodos al mismo tiempo tienen el mismo resultado para un cierto valor almacenado en él, es decir, su almacenamiento compartido es consistente. El clúster tiene la naturaleza de recuperación automática. Cuando falla una pequeña cantidad de nodos, el funcionamiento normal del clúster no se verá afectado. Cuando la mayoría de los nodos del clúster fallan, el clúster detendrá el servicio (no se producirá ningún resultado incorrecto devuelto).

4.2 Aplicación de Raft en DolphinDB

DolphinDB introduce el protocolo balsa para completar la alta disponibilidad de metadatos, es decir, la alta disponibilidad de nodos de control. El nodo de control en DolphinDB almacena los metadatos del sistema de archivos distribuido Si el nodo de control deja de funcionar, todo el sistema estará en un estado inutilizable.

Con la alta disponibilidad respaldada por Raft, podemos activar múltiples nodos de control al mismo tiempo y guardar la misma información de metadatos. Siempre que la mayoría de los nodos estén disponibles en cualquier momento, todo el sistema está disponible.

Para conocer la alta disponibilidad de metadatos, puede consultar el tutorial de implementación de clústeres de alta disponibilidad de DolphinDB .

5 escenarios en los que se debe utilizar Log

El registro anterior se debe utilizar en los siguientes escenarios:

Los escenarios de escritura de datos en tiempo real tienen requisitos para la confiabilidad de los datos y no pueden aceptar la pérdida de datos durante el tiempo de inactividad. Rehacer Log y CacheEngine deben estar habilitados.
En el escenario de escritura de datos, si el número de columnas en la tabla DFS es particularmente grande, se deben habilitar Rehacer Log y CacheEngine.
Si se requiere que la base de datos DFS tenga un escenario de alta disponibilidad, RaftLog debe estar activado.

6 recomendaciones para la optimización del rendimiento general

De acuerdo con la descripción anterior, para mejorar el rendimiento de escritura general de la base de datos, existen las siguientes sugerencias:

Configure el directorio de almacenamiento de todos los metadatos y el directorio de almacenamiento Redo Log en el SSD, y use SSD de grado industrial si es posible. Las recomendaciones específicas son las siguientes:

dfsMetaDir: directorio de almacenamiento de metadatos del nodo de control, configurado en el disco SSD, configurado en controller.cfg.
chunkMetadir: el directorio de almacenamiento de metadatos del nodo de datos, configurado en el disco SSD y configurado en cluster.cfg.
rodoLogDir: configúrelo en el disco SSD y configúrelo en cluster.cfg.
persistenceDir: la ruta de almacenamiento de los datos de transmisión, se recomienda configurarla en el disco SSD. Establecer en cluter.cfg.
logFile: el registro de ejecución de cada nodo, que registra el estado de ejecución del nodo, la información de error, etc., se puede escribir en el disco HDD. Establecer en controller.cfg, agent.cfg, cluster.cfg.
batchJobDir: el directorio de registro de las tareas de procesamiento por lotes, como los registros de tareas enviados por submiJob, se puede escribir en el disco HDD. Establecido en cluster.cfg.
jobLogFile: el registro de consultas de cada nodo, registra la ejecución de cada consulta y se puede escribir en el disco HDD. Establecido en cluster.cfg.

2. Configure razonablemente el tamaño de la memoria y el ciclo de recolección de basura de RedoLog. Generalmente, se recomienda configurar la memoria para que no exceda 4G, no menos de 1G, y el ciclo de reciclaje sea de 60 segundos.

3. Configure razonablemente el tamaño de memoria de CacheEngine. No debe ser demasiado grande ni demasiado pequeño, y el máximo no excede 1/4 de la configuración de memoria del nodo de datos. El tamaño de memoria de 1 ~ 4G es adecuado para la mayoría de situaciones , combinando específicamente los recursos reales de la máquina y los datos de escritura. Se determina la velocidad.