¿Por qué se prefiere el sistema de archivos para los registros en lugar de RDBMS?

1. Demasiadas cosas pueden fallar con la base de datos y el registro de estas fallas también es importante.

2. A menos que tenga un sistema de base de datos que permita transacciones autónomas (o ninguna transacción), el registro requeriría una conexión separada, por lo que una reversión o confirmación en el registro no interfiere con la reversión o confirmación en la aplicación.

3. Muchas cosas vale la pena registrar durante el inicio, es decir, posiblemente antes de que se haya establecido la conexión de la base de datos.

4. En lo que podría ser una configuración típica, cada día se crea un nuevo archivo de registro, los archivos de registro antiguos se comprimen y se guardan durante 2 semanas, antes de que finalmente se eliminen. No es fácil hacer lo mismo en un RDBMS.

He visto registros escritos anteriormente en la base de datos (y, a veces, obtienes opciones configurables para el registro, donde el seguimiento va al archivo, los errores en la base de datos y los registros generales de eventos de Windows).

Las razones principales son la velocidad y el tamaño, ya que permitir un seguimiento puede producir vastas y vastas caídas de registros. He rastreado archivos de registro de tamaño de gigabytes. La otra razón principal es que la lectura de los registros debe ser secuencial, no hay una necesidad real de consultar el registro, excepto para encontrar un determinado error o entrada, y la búsqueda en el archivo funciona perfectamente bien para eso.

La velocidad es una de las razones; otros son:

• Eliminando puntos de falla. Un sistema de archivos rara vez falla en condiciones donde un DBMS no lo haría, pero existen muchas condiciones de error en las bases de datos que simplemente no existen en los sistemas de archivos.
• Accesibilidad de baja tecnología. Si las cosas van realmente mal, puede iniciarse en un shell de rescate o montar el disco en un sistema diferente, y aún tener las herramientas adecuadas disponibles para inspeccionar los archivos de registro. Si es una base de datos, no está en ninguna parte sin un servidor de base de datos en funcionamiento.

Primero que nada.

  

Y eso podría incluso fallar en circunstancias particulares si no se prestara mucha atención.

Las transacciones de la base de datos no pueden fallar cuando no tienes cuidado?

Escribir en un archivo de texto tiene varios beneficios, el más importante es

• El texto es legible por humanos. Cualquiera puede abrir un archivo de registro con un editor de texto básico y ver qué son los mensajes. No necesita comprender cómo está organizada la base de datos.
• velocidad. Escribir texto en disco es mucho más rápido que un servicio de base de datos que determina dónde va el texto en una base de datos, escribiéndolo allí y asegurando que la transacción se complete.

Subes a Apache específicamente, así que discutiré esto en detalle.

Apache puede configurarse para iniciar sesión en una base de datos, aunque requiere un complemento externo para hacerlo. El uso de dicho complemento puede facilitar el análisis de registro, pero solo si tiene la intención de escribir su propio software de análisis de registro. Los analizadores de registro estándar disponibles asumen que sus registros están en archivos, por lo que no podrá usarlos.

Cuando estaba haciendo esto, también experimenté problemas de confiabilidad: si se llenaba el búfer de escritura del servidor de la base de datos (lo que puede suceder con mysql si usa su cuota del sistema de archivos para el usuario con el que se ejecuta) comienza a poner en cola las consultas hasta son capaces de continuar, momento en el que Apache comienza a esperar a que finalice, lo que da como resultado solicitudes bloqueadas en su sitio web.

(Este problema ahora puede solucionarse, por supuesto, hace muchos años que hice esto)

Veamos esto en algunas capas:

1. capa de la máquina
2. capa del sistema operativo
3. capa de servicio
4. capa de aplicación

En resumen:

• En la capa de la máquina, realmente no puede hacer un registro que no sea algún tipo de volcados.
• En la capa del sistema operativo, puede hacer el registro, pero en realidad solo tiene el sistema de archivos disponible.
• Los servicios pueden iniciar sesión en el sistema de archivos, pero no pueden confiar en que otros servicios se estén ejecutando, por lo que no pueden iniciar sesión allí.
• Las aplicaciones pueden iniciar sesión en los servicios y en el sistema de archivos.

Luego tenemos el enfoque basado en casos de uso:

¿Desea registrar errores específicos del nodo en un RDBMS escalado horizontalmente en el que necesita realizar un trabajo adicional para encontrar el error de un nodo específico cuando podría abrir el capó de un nodo y verlo allí? Por otro lado, su aplicación posiblemente debería iniciar sesión en un RDBMS para recopilar errores y avisos a nivel de aplicación.

¿Qué sucede cuando RDBMS necesita hacer el registro por sí mismo porque la base de datos no se puede escribir?

Un sistema de archivos es una base de datos. De hecho, es una base de datos jerárquica más simple en lugar de un DBMS relacional, pero sin embargo es una base de datos.

La razón por la que el registro en un sistema de archivos es popular es porque los registros de texto encajan bien con la filosofía de Unix: "El texto es la interfaz universal".

Unix se había desarrollado con muchas herramientas de propósito general que pueden funcionar bien con registros de texto. No importa si los registros de texto son producidos por mysql, apache, su aplicación personalizada, software de terceros que no tiene soporte, el administrador de sistemas puede usar herramientas estándar de Unix como grep, sed, awk, sort, uniq, cut, tail , etc, para rastrear a través de los registros de todos modos.

Si cada aplicación inicia sesión en su propia base de datos, una en MySQL, otra en Postgres, otra en Elasticsearch, otra quiere iniciar sesión en ELK, otra solo puede iniciar sesión en MongoDB, entonces tendrá que aprender veinte herramientas diferentes para rastrear Registros de cada aplicación. El texto es un medio universal al que todos pueden acceder.

Incluso cuando logra hacer que todos los registros se dirijan a una sola base de datos, digamos MySQL, es posible que cada aplicación quiera registrar con diferentes esquemas de tabla, por lo que aún tendría que escribir una herramienta personalizada para consultar el Registros para cada aplicación. Y si de alguna manera abarrotaba todas las aplicaciones para iniciar sesión en un solo esquema, es probable que descubras que ese esquema genérico realmente no te puede contar la historia completa de cada aplicación, por lo que aún tienes que analizar los textos de registro de todos modos.

El registro en una base de datos a menudo no hace las cosas mucho más fáciles en la práctica.

El registro en una base de datos puede ser útil cuando tiene un análisis específico que tiene en mente, o para un requisito de retención de auditoría específico, para el cual puede diseñar un esquema de base de datos específico para recopilar solo los datos para esos fines específicos. Pero para el análisis forense y la depuración, y cuando recopila un registro sin tener un objetivo específico en mente, los registros de texto suelen ser lo suficientemente buenos como para que el costo de aprender o crear las herramientas especializadas no valga la pena.

Complejidad. Agregar RDBMS aumentará la complejidad de todo el sistema astronómicamente. Y la capacidad de administrar la complejidad es lo principal que distingue a los programadores de los productores de código fuente.

  

¿Es velocidad o facilidad de mantenimiento o algo más?

Velocidad.