为什么首选文件系统而不是RDBMS日志？

44

从标题可以清楚地看出问题。例如，无论使用何种规模，Apache都将其访问和错误日志保存在文件中而不是RDBMS中。

对于RDMS，我们只需要编写SQL查询，它将完成工作，而对于文件，我们必须确定特定的格式，然后编写正则表达式，或者可能是解析器来操纵它们。如果没有给予足够的照顾，在某些情况下甚至可能失败。

但是，每个人似乎都更喜欢使用文件系统来维护日志。我对这些方法都不抱有偏见，但我想知道为什么要这样进行。是速度还是可维护性或其他？

— 亚西尔
source

10

那么，如果您的日志系统登录到数据库，您将如何记录数据库错误（例如，数据库不可用）？

— Marjan Venema

17

@Marjan如果失败，我将如何记录文件系统错误？

— Yasir

5

确实如此，但是如果失败了，那么您的数据库也可能无法访问...毕竟，在没有文件系统的情况下，它将在哪里/如何写入表中？

— Marjan Venema

2

@Yasir：将所有日志消息发送到syslog服务器，然后再登录到文件系统:)

— Brian

1

@MarjanVenema如果游戏毫无意义怎么办。如果本地磁盘已满，怎么办？您的日志记录将失败，但是app和os可以继续运行。如果您要登录到远程数据库服务器，尽管仍然可以登录。可以存储日志消息有其优点和缺点，而这最好取决于您要摆脱日志的内容。抱歉，让牧群回到文件日志是一种正确的方法。

— 安迪

37

数据库可能发生太多故障，记录这些故障也很重要。
除非您的数据库系统允许自主事务（或根本没有事务），否则日志记录将需要单独的连接，因此日志记录中的回滚或提交不会干扰应用程序中的回滚或提交。
许多值得记录的事情在启动期间发生，即可能在数据库连接建立之前。
在典型的设置中，每天都会创建一个新的日志文件，将旧的日志文件压缩并保存2周，然后再将其删除。在RDBMS中做同样的事情并不容易。

— 用户名
source

1

我尝试了这个实验，但效果不佳。RDBMS的设计思想是，相对于读取次数而言，数据写入相对不频繁。日志记录基本上是相反的。您一直在写作，很少阅读。这是惹恼您的DBA的好方法。

— JimmyJames

1

但是，人们可能会考虑使用InfluxDB之类的时序数据库系统来保存日志。在我看来，它比PostgreSQL更适合该任务。尽管如此，相对于老式日志文件的优势仍然很少。

— user281377 '17

将非关系数据库与令牌索引等配合使用绝对有用，而且如果您明智地选择，它们也可以应付自如。这是诸如杂弹和水槽等工作原理的一部分。

— JimmyJames

＃4并不是真正的问题。 DELETE FROM dbo.Log WHERE LogDate < today minus 2 weeks

— 罗伯特·哈维

@RobertHarvey除非您在重负载环境中尝试使用，否则此方法效果很好，在这种环境下，此类批量操作可能会导致严重问题，而无需采取额外的预防措施。重做日志填写你的磁盘空间，撤销表空间变得太满，复制变得非常繁忙的复制删除等

— user281377

16

我以前看过将日志写入数据库（有时您会获得可配置的日志记录选项，其中跟踪记录到文件，错误记录到数据库，致命事件到Windows事件日志）。

主要原因是速度和大小，启用某些跟踪会产生大量的日志记录质量-我已经浏览了千兆字节的日志文件。另一个主要原因是，读取日志需要顺序进行，除了查找某个错误或条目外，没有真正的查询日志的必要，而在文件中查找在此方面效果很好。

— gbjbaanb
source

但是我对此感到困惑。我的记事本，写字板，gedit或notepad ++或任何网络浏览器都不愿意打开4GB大小的文件。但是，同一浏览器将能够向我显示一千个页面的列表，每个页面包含打印的500条记录。对？

— Yasir

7

@Yasir，因为您正在使用尝试将整个文件加载到内存中的编辑器。尝试使用能够“流式处理”大文件的更智能的编辑器。Vim是一个很好的例子。

— nakhli 2011年

6

@Yasir：的确如此，但是您正在尝试优化错误的东西。在绝大多数情况下，日志是写入的，而从未读取。因为这是常见的情况，所以您可以非常快速地创建日志。

— unholysampler 2011年

5

嗯，我之前已经完成了对数据库的日志记录，并且能够轻松查询日志消息是非常有益的，特别是当我们打开调试级别的日志记录以跟踪难以复制的错误时。

— 安迪

2

@gbjbaanb我没有发现它被高估了，坦率地说，您建议使用标记线并剪切和粘贴进行查询是一个笑话。它不只是搜索，分析趋势，发现有比别人更多的问题的服务器，什么样的错误，使用者看到最常等

— 安迪

15

速度是原因之一；其他是：

消除故障点。在没有DBMS的情况下，文件系统很少会失败，但是数据库中有很多错误条件，这些错误条件在文件系统中根本不存在。
技术可访问性低。如果情况确实真的很糟，则可以引导至应急外壳，或将磁盘安装在其他系统上，并且仍然具有足够的工具来检查日志文件。如果是数据库，那么没有数据库服务器运行就无处不在。

— 炸弹
source

3

首先。

如果没有给予足够的照顾，在某些情况下甚至可能失败。

如果不小心，数据库事务不会失败？

写入文本文件有很多好处，最重要的是

文字是人类可读的。任何人都可以使用基本的文本编辑器打开日志文件，然后查看消息内容。您无需了解数据库的组织方式。
速度。将文本写入磁盘要比数据库服务确定文本在数据库中的位置，在数据库中写入文本并确保事务完成要快得多。

— 不正确的采样器
source

显然，如果我们不小心，任何事情都会失败。但是对于这个问题，我指的是高级程序员。作为一个简单的示例，程序员可能想使用特定字符来分隔值。因此，他/她的正则表达式将像超级按钮一样工作，但是当相同的字符包含在值块中时，它将失败。这样，他需要照顾类似的可能情况，如果他保存在数据库中，则无需考虑这些情况。另外，您能看到我对gbjbaanb答案的评论吗？

— Yasir

1

而且，如果您正在手动编写SQL，您将遇到同样的问题。区别在于写入将失败（或破坏您的数据），而不是使某些开发人员稍稍烦恼，因为他的搜索字符串带来了一些不良结果。是的，有些框架意味着您不必编写SQL，但是每增加一层都会减慢该过程。记住，这只是日志记录。您用于记录日志的每个周期都是您不用于进行实际工作的周期。

— unholysampler 2011年

@unholysampler您的性能参数很弱，可以非常快地在数据库的后台线程上进行日志记录，并且登录到f时虽然也可能不是更快，但也不是免费的，尤其是如果它不是在后台完成的话。

— 安迪

2

您专门提出了Apache，因此我将详细讨论。

尽管需要外部插件才能将Apache配置为登录到数据库。使用这样的插件可以使日志分析更加容易，但前提是您打算编写自己的日志分析软件。标准的现成日志分析器假定您的日志位于文件中，因此您将无法使用它们。

在执行此操作时，我还遇到了可靠性问题：如果数据库服务器的写缓冲区已满（如果您用完了要运行的用户的文件系统配额，这可能在mysql中发生），它将开始对查询进行排队，直到他们能够继续，此时Apache开始等待它完成，从而导致对您的网站的挂起请求。

（当然，现在可以解决此问题-我是在很多年前完成的）

— 朱尔斯
source

1

文件系统是一个数据库。它确实是一个更简单的分层数据库，而不是关系DBMS，但是它仍然是数据库。

记录到文件系统之所以流行是因为文本日志与Unix哲学非常吻合：“文本是通用接口”。

Unix开发了许多通用工具，这些工具可以很好地处理文本日志。文本日志是否由mysql，apache，您的自定义应用程序，长期不支持的第三方软件生成都无所谓，sysadmin可以使用标准的Unix工具，例如grep，sed，awk，sort，uniq，cut，tail等等，以完全相同的方式浏览日志。

如果每个应用程序都登录到其自己的数据库，一个登录到MySQL，另一个登录到Postgres，另一个登录到Elasticsearch，另一个想要登录到ELK，另一个只能登录到MongoDB，那么您将必须学习二十种不同的工具来拖曳每个工具的日志。应用。文本是每个人都可以登录的通用媒体。

即使设法使所有日志都进入一个数据库（例如MySQL），您仍可能会发现每个应用程序都希望使用不同的表模式进行日志记录，因此仍然需要编写自定义工具来查询每个数据库的日志应用。而且，如果您以某种方式挤满了每个应用程序以登录到单个架构，则可能会发现该通用架构无法真正告诉您每个应用程序的完整情况，因此无论如何您仍然必须解析日志文本。

在实践中，登录数据库通常并没有真正使事情变得容易得多。

当您有特定的分析或特定的审计保留要求时，登录数据库可能会很有用，为此您可以设计特定的数据库模式以仅出于这些特定目的收集数据。但是对于取证和调试以及在收集日志时没有考虑到特定目标的情况下，文本日志通常足够好，以致于学习或创建专用工具的成本通常是不值得的。

— 烈瑞恩
source

0

让我们从几层来看一下：

机器层
操作系统层
服务层
应用层

简单来说：

在计算机层上，除了某种类型的转储之外，您实际上无法执行日志记录。
在OS层上，您可以进行日志记录，但实际上只有文件系统可用。
服务可以登录到文件系统，但是它们不能信任其他正在运行的服务，因此它们不能登录到那里。
应用程序可以登录服务和文件系统。

然后，我们有了基于用例的方法：

您是否想将特定于节点的错误记录到水平缩放的RDBMS中，当您可以弹出一个节点的引擎盖并在那里看到它时，您需要采取额外的工作来查找特定节点的错误吗？另一方面，您的应用程序可能应该登录到RDBMS来收集应用程序级别的错误和通知。

当RDBMS由于无法写入数据库而需要自行记录日志时，会发生什么情况？

— 奥杰拉斯克
source

-2

复杂。添加RDBMS将在天文上增加整个系统的复杂性。而管理复杂性的能力是使程序员与源代码生产者区别开来的主要因素。

— one
source

1

您能否扩展一下复杂性的含义，因为它涉及到登录到数据库还是文件系统？根据我的经验，在业务环境中，复杂性没有显着差异。

— 亚当·祖克曼

真？SqlLite天文增加了复杂性吗？尽管Web服务器通常不需要数据库，但是许多LOB应用程序已经在使用数据库，因此根本没有额外的成本。

— 安迪

@AdamZuckerman当然，任何RDBMS都需要维护，容易损坏，可能需要特殊的调整，可能会受到不良配置的影响，可能需要特殊的恢复，带来自己的局限性，具有自己的依赖性，受支持的平台，受支持的平台，升级问题，Bug，许可等。。

— noonex

@Andy首先，SQLite在传统意义上不是RDBMS-它是“嵌入式RDBMS”。是的-需要使用SQLite进行日志记录会大大增加复杂性。

— noonex

1

@noonex当RDBMS不区分嵌入式服务器和完整服务器时，您可以任意区分。SqlLite提供了ACID合规性，这实际上是RDBMS的目的。它增加了很多复杂性吗？我只能想象，除了最琐碎的应用程序之外，您什么都没做。最后，出色的工作完全忽略了我关于许多LOB应用程序的观点，无论如何，它们已经需要数据库。

— 安迪

-4

是速度还是可维护性或其他？

速度。

— 洛特
source