存储许多日志文件

Question

我有一个系统通过http接收来自不同地方的日志文件（＆gt; 10k生产者，每天10个日志，每个约100行文本）。

我想存储它们以便能够计算misc。每晚对它们进行统计，输出它们（按到达日期或第一行内容排序）......

我的问题是：存储它们的最佳方式是什么？

• 平面文本文件（具有正确锁定），每个上传文件一个文件，每天一个目录/生产者
• 平面文本文件，所有生产者每天一个（大）文件（此处的问题将是索引和锁定）
• 带有文本的数据库表（由于内部原因，MySQL是首选）（带有DB清除的pb，因为删除可能会很长！）
• 数据库表，每行文本一条记录
• 带分片的数据库（每天一个表），允许简单的数据清除。 （这是分区。但是我有权访问的mysql版本（即内部支持）不支持它）。
• 基于文档的DBàlacouchdb或mongodb（问题可能与索引/成熟度/摄取速度有关）

有什么建议吗？

Answer 1

（免责声明：我在MongoDB上工作。）

我认为MongoDB是最佳的日志记录解决方案。它非常快，因为它可能比发送数据更快地插入数据。您可以对数据（例如，日期或日志级别的范围）以及索引和字段或字段组合进行有趣的查询。它也很好，因为你可以随机地向日志添加更多字段（“oops，我们想要一些堆栈跟踪字段”）并且它不会引起问题（就像使用平面文本文件一样）。

就稳定性而言，很多人已经在生产中使用MongoDB（参见http://www.mongodb.org/display/DOCS/Production+Deployments）。在我们进入1.0之前，我们还想要添加一些其他功能。

Answer 2

我会选择第一个解决方案。

我不明白为什么你需要DB。似乎所有你需要的是扫描数据。将日志保持在最“原始”状态，然后处理它，然后每天创建一个tarball。

聚合的唯一原因是减少文件数量。在某些文件系统上，如果在目录中放置N个以上的文件，性能会迅速下降。检查您的文件系统，如果是这种情况，请组织一个简单的2级层次结构，例如，使用生产者ID的前2位数作为第一级目录名。

Answer 3

我会在每次上传时写一个文件，并按照您的第一个建议写一个目录/天。在一天结束时，对文件运行处理，然后tar.bz2目录。

tarball仍然可以搜索，并且可能非常小，因为日志通常可以很好地压缩。

对于总数据，您说的是每天1GB（校正10MB）未压缩。这可能会压缩到100MB或更少。我在使用bzip2的日志文件上看到了200x压缩。您可以轻松地将压缩数据存储在文件系统上多年，而无需担心。对于其他处理，您可以编写可以搜索压缩tarball并生成更多统计信息的脚本。

Answer 4

因为你想存储它们以便能够计算misc。每晚对它们进行统计，输出它们（按到货日期或第一行内容排序）......您预计每天会有100,000个文件，总计10,000,000行：

我建议：

1. 使用以下格式将所有文件存储为常规文本文件：yyyymmdd / producerid / fileno。
2. 在一天结束时，清除数据库，然后加载当天的所有文本文件。
3. 加载文件后，很容易从数据库中获取统计数据，并以任何所需格式发布。 （甚至可能是另一个“统计数据”数据库）。你也可以生成图表。
4. 为了节省空间，您可以压缩每日文件夹。由于它们是文本文件，因此它们可以很好地压缩。

因此，您只能使用数据库来轻松聚合数据。如果过程不起作用，您还可以通过执行相同的步骤来重现较旧日的报告。

Answer 5

根据我的经验，如果我们谈论数据库解决方案，单个大表的执行速度比几个链表快得多。特别是在写入和删除操作上。例如，将一个表拆分为三个链接表会使性能降低3-5倍。这非常粗糙，当然这取决于细节，但通常这是风险。当数据量变得非常大时，情况会变得更糟。存储日志数据的最佳方式IMO不是平面文本，而是结构化形式，以便您以后可以进行有效的查询和格式化。管理日志文件可能很痛苦，尤其是当它们有很多来自许多来源和位置时。查看我们的solution，IMO可以为您节省大量的开发时间。