为什么日志存储在平面文件中，而不是数据库 (SQL)？答案

【问题标题】：Why are logs stored in flat files, rather than a database (SQL)?为什么日志存储在平面文件中，而不是数据库 (SQL)？
【发布时间】：2011-07-04 01:15:31
【问题描述】：

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

使用平面文件有什么好处（速度、延迟、写入时间等），还是我只是遗漏了什么？

【问题讨论】：

【解决方案1】：

不保证您在服务器上有一个数据库。

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

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

为什么在简单有效时使用复杂。当 Apache（等）首次开发时，开源（免费、无处不在）的 DB 不可用。

等等。等等。

【讨论】：

如果我可以插话：数据库是为密集的读/写操作而设计的，而日志从根本上是一种始终写入、在紧急情况下只读的努力。由于这种用法不匹配，部署事务性 RDBMS 来存储日志通常是大材小用。

【解决方案2】：

其中很多也是遗产。虽然数据库服务器和具有 100 GB 存储（如果不是 TB 和 GB 的 RAM）的机器是丰富的（如果不是常态的话），但大多数经验丰富的服务器都来自内存是系统资源被低得多的负载充分利用的时代。

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

亲吻。日志分析工具不应成为日志编写的一部分。

【讨论】：

【解决方案3】：

有一个永恒的原则，即活动部件越少，出错的点就越少。您可以最大限度地减少依赖关系，从而最大限度地减少可能出现错误的地方。它的速度也很快，因为它很简单，而且是一个高负载服务器，您不希望日志记录使系统陷入困境。

有趣的是，正是这一原理让查尔斯·林德伯格的单引擎飞机成功地直飞大西洋，而其他许多更大的飞机在他之前都失败了。保持简单:)

【讨论】：

【解决方案4】：

虽然这里的其他答案都是正确的（KISS 主体等），但我见过一个项目，其中日志记录填满了服务器的硬盘驱动器，他们必须构建自动化来清理日志。要解决这个问题，可能需要实现滚动备份/最大日志大小功能，或者制定计划任务 (cron) 来移动或删除日志。

没有免费的午餐。

【讨论】：

【解决方案5】：

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

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

每次我们在数据库连接中出现异常时，都会回滚日志记录。

（我想我不应该说总是...就在日志记录后发生回滚时。不过，这还是有一段时间令人困惑！）

【讨论】：