【发布时间】:2011-03-06 14:16:15
【问题描述】:
大多数日志似乎是纯文本,而不是放在 MySQL/其他类型的数据库中,这是有原因的吗?
在我看来,将它们放入数据库会使分析变得更加容易……但这会以牺牲速度或其他方式为代价吗?
(我不太关心可移植性,显然你会有用于数据库连接的文本日志。)
【问题讨论】:
大多数日志似乎是纯文本,而不是放在 MySQL/其他类型的数据库中,这是有原因的吗?
在我看来,将它们放入数据库会使分析变得更加容易……但这会以牺牲速度或其他方式为代价吗?
(我不太关心可移植性,显然你会有用于数据库连接的文本日志。)
【问题讨论】:
我能想到两大原因:
首先,在简单地将信息附加到文件时,数据库比文本文件慢。使用数据库,您必须建立连接、通过网络传输数据、将其存储在索引结构中等等。使用文件,只需将错误写入本地磁盘即可。
其次,有时您要记录的内容与数据库损坏有关。如果本地磁盘坏了,你会遇到比尝试生成日志文件更大的问题。但即使其他一切正常,您也可以记录数据库中断。
话虽如此,在很多情况下,我想要记录的信息仅在应用程序正常运行并且我已经有数据库连接时才相关。在这些情况下,我会直接登录到 MySQL。
【讨论】:
虽然您不关心可移植性,但我相信这是很大一部分原因。文件 I/O 几乎是通用的,并且具有极其一致的 API。其他优势包括:
也就是说,如果应用程序的性质适合这种情况,那么登录到数据库并没有错,而且我已经看到很多应用程序都这样做了。
【讨论】:
数据库在内存、存储空间和效率方面包含大量开销。将新记录添加到数据库或修改现有记录要慢得多。 (此外,许多人不熟悉 SQL 和/或设置数据库的细节。)
但是,如果您需要通过简单的文本文件难以获得的分析或度量评估功能,那么这当然没有问题。这是一个非常具体的情况。
【讨论】:
(其他人已经指出了基于文件的日志记录的许多优点。)
我认为,当在远程机器上收集日志(例如,通过 Linux 上的 syslog/rsyslog)用于备份时,数据库日志记录会变得更加有用:如果原始机器受到破坏并且其日志被更改,这将很有用。在这种情况下,收集数据库中的日志(尤其是在远程机器上)很有用,因为它可以帮助整理这些日志。您还可以通过phpLogCon 等工具更方便地浏览日志,或使用自定义网页浏览日志(如果您只是进行一些随意的监控,这通常比登录机器更容易)。
话虽如此,远程日志记录、记录到数据库和拥有一个不错的工具来浏览日志是相当独立的(我认为 phpLogCon 也可以处理文件日志)。如果我将日志存储在数据库中,我也会同时将日志存储在一个文件中,如果只是为了在与数据库的连接断开时能够读取。
【讨论】:
请务必注意,您没有理由不能将日志写入文件(正如其他人指出的那样,它非常快速、高效且健壮),然后将数据卸载到数据库中(可能在某些其他机器)以执行分析,该分析将通过拥有典型的数据库功能来加速。当然,这是可能的,因为日志数据通常不需要立即处理——因此将数据库的所有开销和脆弱性推迟到需要时是有意义的。
【讨论】:
从历史上看,数据库非常昂贵,您当然不想将宝贵的数据库许可证浪费在日志上。然而,今天的数据库相对便宜,处理也是如此。使用数据库记录日志可能不会在经济上杀死您。
日志文件的优点是你可以一直写到它的末尾。与使用数据库服务器相比,这是一种相对有效的操作。
数据库的优势在于您可以在数据关系中构建日志数据,然后可以使用 SQL 对其进行分析。这可以让您深入了解软件的操作。
使用 SQLite 作为日志数据库,您可以两全其美。 SQLite 是一个带有 SQL 引擎的库,您可以将其链接到您的程序中。您可以使用 SQLite API 打开数据库、运行 SQL 并关闭数据库,而不是 fopen/fwrite/fclose。没有数据库服务器,因为 SQLite 引擎操作在应用程序的进程中运行……就像 fopen/fwrite/fclose 一样。一旦您在 SQLite 数据库中捕获数据(全部存储在一个简单的文件中),您就可以使用 SQL 来分析您的日志数据。以http://www.squidoo.com/sqlitehammer#module5800826 为例。
-------- 2010 年 8 月编辑 ------------
自SQLite version 3.7.0 起,SQLite 的开发人员已经实现了预写日志记录。这可以实现更快的写入。查看this video 了解更多详情。由于编写速度更快,SQLite 作为日志数据库更加有用。
【讨论】: