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

44

La pregunta debe quedar clara por su título. Por ejemplo, Apache guarda sus registros de acceso y error en archivos en lugar de RDBMS, sin importar cuán grande o pequeña escala se esté utilizando.

Para RDMS solo tenemos que escribir consultas SQL y hará el trabajo, mientras que para los archivos debemos decidir un formato particular y luego escribir expresiones regulares o pueden ser analizadores para manipularlos. Y eso podría incluso fallar en circunstancias particulares si no se pagara mucho cuidado.

Sin embargo, todo el mundo parece preferir el sistema de archivos para mantener los registros. No estoy predispuesto contra ninguno de estos métodos, pero me gustaría saber por qué se practica así. ¿Es velocidad o mantenibilidad o algo más?

— Yasir
fuente

10

Entonces, ¿cómo registraría los errores de la base de datos (db no disponible, por ejemplo) si su sistema de registro se registra en una base de datos?

— Marjan Venema

17

@Marjan ¿Cómo registraría los errores del sistema de archivos si falla?

— Yasir

55

Es cierto, pero si eso falla, es probable que su base de datos también sea inaccesible ... Después de todo, ¿dónde / cómo escribiría en sus tablas sin el sistema de archivos?

— Marjan Venema

2

@Yasir: envíe todos los mensajes de registro a un servidor syslog antes de iniciar sesión en el sistema de archivos :)

— Brian

1

@MarjanVenema, ¿y si el juego no tiene sentido? Qué sucede si el disco local está lleno, su registro fallará pero la aplicación y el sistema operativo pueden continuar. Si está iniciando sesión en un servidor de base de datos remoto, aún podrá iniciar sesión. Hay ventajas y desventajas para almacenar los mensajes de registro, y lo que es mejor depende de lo que intente obtener del registro. Lo siento, dejaré que el rebaño regrese al registro de archivos es la única forma verdadera.

— Andy

37

Demasiadas cosas pueden fallar con la base de datos y registrar estas fallas también es importante.
A menos que tenga un sistema de base de datos que permita transacciones autónomas (o ninguna transacción en absoluto), el registro requeriría una conexión separada para que una reversión o confirmación en el registro no interfiera con la reversión o confirmación en la aplicación.
Muchas cosas que vale la pena registrar ocurren durante el inicio, es decir, posiblemente antes de que se haya establecido la conexión de la base de datos.
En lo que podría ser una configuración típica, se crea un nuevo archivo de registro todos los días, los archivos de registro antiguos se comprimen y se mantienen durante 2 semanas, antes de ser eliminados. No es fácil hacer lo mismo en un RDBMS.

— usuario281377
fuente

1

Intenté este experimento y no salió bien. RDBMS está diseñado en torno a la idea de que los datos se escriben con poca frecuencia en relación con el número de veces que se leen. El registro es básicamente lo contrario. Escribes todo el tiempo y lees raramente. Esta es una excelente manera de molestar a su DBA.

— JimmyJames

1

Sin embargo, se podría considerar el uso de un sistema de base de datos de series temporales como InfluxDB para mantener registros; Me parece que es un poco más adecuado para la tarea que, por ejemplo, PostgreSQL. Aún así, la ventaja sobre los archivos de registro anticuados apenas existe.

— user281377

Usar una base de datos no relacional con indexación de tokens, etc. es definitivamente útil y si elige con prudencia, pueden manejar la manguera contra incendios. Esto es parte de cómo funcionan cosas como splunk y flume.

— JimmyJames

# 4 no es realmente un problema. DELETE FROM dbo.Log WHERE LogDate < today minus 2 weeks

— Robert Harvey

@RobertHarvey Esto funciona bien hasta que lo intente en un entorno de carga pesada, donde tales operaciones masivas pueden causar problemas serios sin precauciones adicionales. Registros de rehacer llenado su espacio de disco, deshacer de tablas se llene demasiado, la replicación llegando a ser muy ocupado con la replicación de la eliminación etc

— user281377

16

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

Las razones principales son la velocidad y el tamaño, lo que permite un poco de rastreo puede producir vastas, vastas cualidades de registro: he rastreado a través de archivos de registro de gigabytes de tamaño. La otra razón principal es que la lectura de los registros debe ser secuencial, no hay necesidad real de consultar el registro, excepto para encontrar un cierto error o entrada, y encontrar en el archivo funciona perfectamente bien para eso.

— gbjbaanb
fuente

Pero tengo una confusión para esto. Mi bloc de notas, wordpad, gedit o notepad ++ o cualquier navegador web no estarán contentos de abrir un archivo de 4GB de tamaño. Sin embargo, el mismo navegador podrá mostrarme una lista de mil páginas, cada una con 500 registros impresos. ¿Derecho?

— Yasir

77

@Yasir porque está utilizando editores que intentan cargar todo el archivo en la memoria. Intente utilizar un editor más inteligente que pueda 'transmitir' el archivo grande. Vim es un buen ejemplo.

— nakhli

66

@Yasir: Esto es cierto, pero está tratando de optimizar lo incorrecto. La gran mayoría de las veces, los registros se escriben y nunca se leen. Entonces, la creación de registros es muy rápida porque es el caso común.

— unholysampler

55

Eh, ya he iniciado sesión en la base de datos y poder consultar fácilmente los mensajes de registro fue inmensamente beneficioso, especialmente cuando activamos el registro de nivel de depuración para rastrear un error difícil de replicar.

— Andy

2

@gbjbaanb No lo encontré sobrevalorado, y francamente sugieres usar líneas de marca y cortar y pegar para consultar es una broma. No es solo buscar, analizamos tendencias para encontrar servidores que tenían más problemas que otros, qué tipo de errores veían los usuarios con más frecuencia, etc.

— Andy

15

La velocidad es una razón; otros son:

Eliminando puntos de falla. Un sistema de archivos rara vez falla en condiciones donde un DBMS no lo haría, pero hay 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 iniciar 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 se trata de una base de datos, no está en ninguna parte sin un servidor de base de datos en ejecución.

— tdammers
fuente

3

Antes que nada.

Y eso podría incluso fallar en circunstancias particulares si no se pagara mucho cuidado.

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

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

El texto es legible por humanos. Cualquiera puede abrir un archivo de registro con un editor de texto básico y ver cuáles son los mensajes. No necesita comprender cómo está organizada la base de datos.
Velocidad. Escribir texto en el 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, lo escribe allí y garantiza que se complete la transacción.

— muestreador
fuente

Obviamente, todo puede fallar si no tenemos cuidado. Pero para esta pregunta me refería a un programador de alto nivel. Como un ejemplo simple, el programador podría desear separar valores usando un carácter en particular. Por lo tanto, su expresión regular funcionará como un hechizo, pero fallará cuando el mismo personaje esté contenido dentro de un bloque de valores. De esta manera, debe ocuparse de posibles casos similares y no necesita pensar en ellos si estuviera ahorrando en DB. Además, ¿puedes ver mi comentario sobre la respuesta de gbjbaanb?

— Yasir

1

Y si está escribiendo a mano su SQL, tiene el mismo problema. La diferencia es que la escritura fallará (o corromperá sus datos) en lugar de molestar a algunos desarrolladores ligeramente porque su cadena de búsqueda arrojó algunos malos resultados. Sí, hay marcos que significan que no tiene que escribir SQL, pero cada capa adicional ralentiza el proceso. Y recuerda que esto es solo iniciar sesión. Cada ciclo que usa para iniciar sesión es un ciclo que no está usando para hacer un trabajo real.

— unholysampler

@unholysampler Su argumento de rendimiento es débil, el registro se puede hacer muy rápido y en un subproceso en segundo plano en una base de datos, y el registro en las f aunque potencialmente más rápido tampoco está libre, especialmente si no se realiza en segundo plano.

— Andy

2

Usted plantea Apache específicamente, así que lo discutiré en detalle.

Apache se puede configurar 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 registros, pero solo si tiene la intención de escribir su propio software de análisis de registros. Los analizadores de registro estándar listos para usar asumen que sus registros están en archivos, por lo que no podrá utilizarlos.

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

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

— Jules
fuente

1

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 no obstante es una base de datos.

La razón por la que iniciar sesión 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 sysadmin puede usar herramientas estándar de Unix como grep, sed, awk, sort, uniq, cut, tail , etc., para rastrear 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ía que aprender veinte herramientas diferentes para rastrear los registros de cada solicitud. El texto es un medio universal en el que todos pueden iniciar sesión.

Incluso cuando logra hacer que todos los registros vayan a una sola base de datos, digamos MySQL, es posible que cada aplicación desee iniciar sesión con diferentes esquemas de tabla, por lo que aún tendría que escribir una herramienta personalizada para consultar los registros de cada uno. solicitud. Y si de alguna manera abarrotó todas las aplicaciones para iniciar sesión en un solo esquema, es probable que descubra que ese esquema genérico realmente no puede contarle la historia completa de cada aplicación, por lo que aún tiene que analizar los textos de registro de todos modos.

Iniciar sesión en una base de datos a menudo no facilita mucho las cosas en la práctica.

Iniciar sesión en una base de datos puede ser útil cuando tiene un análisis específico que tiene en mente, o para un requisito específico de retención de auditoría, 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 registros sin un objetivo específico en mente, los registros de texto suelen ser lo suficientemente buenos como para que el costo de aprender o crear herramientas especializadas a menudo no valga la pena.

— Lie Ryan
fuente

0

Veamos esto en algunas capas:

Capa de la máquina
Capa del sistema operativo
Capa de servicio
Capa de aplicación

En breve:

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

Luego tenemos el enfoque basado en casos de uso:

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

¿Qué sucede cuando el RDBMS necesita iniciar sesión por sí mismo porque no se puede escribir en la base de datos?

— ojrask
fuente

-2

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

— noonex
fuente

1

¿Podría ampliar lo que quiere decir sobre la complejidad en lo que respecta al registro en una base de datos versus un sistema de archivos? Desde mi experiencia, no ha habido una diferencia significativa en la complejidad en un entorno empresarial.

— Adam Zuckerman

De Verdad? SqlLite aumenta la complejidad astronómicamente? Y aunque un servidor web normalmente no necesitaría una base de datos, muchas aplicaciones LOB ya están usando una, por lo que no hay ningún costo adicional.

— Andy

@AdamZuckerman, por supuesto, cualquier RDBMS requiere mantenimiento, es propenso a la corrupción, puede necesitar ajustes especiales, puede verse afectado por una mala configuración, puede necesitar una recuperación especial, tiene sus propias dependencias, dependencias propias, plataformas compatibles, problemas de actualización, errores, licencias, etc. .

— noonex

@Andy antes que nada, SQLite no es RDBMS en sesión clásica, es "RDBMS incrustado". Y sí, requerir SQLite para iniciar sesión aumentará mucho la complejidad.

— noonex

1

@noonex Solo es arbitrario hacer una distinción entre el servidor integrado y el servidor completo, cuando RDBMS no lo hace. SqlLite proporciona conformidad con ACID, que es realmente de lo que se trata RDBMS. ¿Y aumenta mucho la complejidad? Solo puedo imaginar que no has trabajado en nada más que en las aplicaciones más triviales. Finalmente, un buen trabajo ignorando completamente mi punto sobre muchas aplicaciones LOB ya necesitaba una base de datos de todos modos.

— Andy

-4

¿Es velocidad o mantenibilidad o algo más?

Velocidad.

— S.Lott
fuente