为什么日志存储在平面文件中,而不是数据库(SQL)?

时间:2011-02-25 03:29:14

标签: sql ruby-on-rails file logging

为什么Web服务器和其他技术使用平面文件进行日志记录,而不是某种类型的数据库,无论是SQL还是某种KVS或“NoSQL”解决方案?

使用平面文件有什么好处(速度,延迟,写入时间等),还是我只是遗漏了什么?

5 个答案:

答案 0 :(得分:9)

您无法保证在服务器上安装数据库。

如果数据库是问题的一部分,您如何查看日志。

如果数据库不是问题的一部分,使用任何旧的文本编辑器查看日志仍然更简单。

为什么在简单的工作时使用复杂。当Apache(等)最初开发时,开源(免费,无处不在)的数据库并不可用。

等。等等。

答案 1 :(得分:2)

  • 首先,它易于编写。
  • 这很简单......写一个文件是最不容易出错的事情之一。
  • 由于简单,它很快。这适用于磁盘写入和执行操作的CPU时间。

这很多也是遗产。虽然数据库服务器和机器具有100千兆字节的存储空间(如果不是太字节和RAM)很多,如果不是常态,大多数经验丰富的服务器都来自内存系统资源充分利用低负载的时间。

但大多数情况下这很简单。为什么要依赖SQLite(作为简单的嵌入式SQL服务),确保您的许可证兼容,保持适当的版本,并且没有潜在的错误或安全问题......除了顺序插入之外什么都不做?

KISS。日志分析工具不应该是日志写入的一部分。

答案 2 :(得分:2)

有一个永恒的原则,即移动部件越少,出现问题的点越少。您最小化依赖性,从而最大限度地减少可能发生错误的位置。它也很快,因为它很简单,而且是一个高负载的服务器,你不希望日志记录陷入困境。

有趣的是,同样的原则使得查尔斯林德伯格的单引擎飞机成功地在大西洋上不停地飞行,而许多其他更大的飞机在他之前失败了。保持简单:)

答案 3 :(得分:1)

虽然这里的其余答案都是正确的(KISS校长等),但我看到一个项目,其中日志记录填满了服务器的硬盘,他们必须构建自动化来清理日志。要解决此问题,可能必须实现滚动备份/最大日志大小功能,或者使计划任务(cron)移动或删除日志。

没有免费的午餐。

答案 4 :(得分:0)

这就是我们在工作中停止使用DB日志的原因。

try
{
    tx.Begin();
    // Exception here!
    tx.Commit();
}
catch(Exception ex)
{
    LogToDB(ex);
    tx.Rollback();
}

每当我们在数据库连接中发生异常时,就会回滚日志记录。

(我想我不应该总是这么说......就在伐木之后发生了回滚。但是,这种情况有点令人困惑!)