许多日志文件的存储

11

我有一个系统,通过HTTP从不同的地方接收日志文件(>10k个生产者,每天10个日志,每个日志约100行文本)。

我想要将它们存储起来,以便每晚能够对它们进行各种统计,并导出它们(按到达日期或第一行内容排序)...

我的问题是:最佳的存储方式是什么?

  • 使用平面文本文件(带有适当的锁定),每个上传的文件一个文件,每个生产者一天一个目录
  • 使用平面文本文件,每天为所有生产者使用一个(大)文件(此处问题在于索引和锁定)
  • 使用包含文本的数据库表(由于内部原因,MySQL更受欢迎)(删除时可能会出现问题,因为删除可能非常耗时!)
  • 使用每行文本一个记录的数据库表
  • 使用分片的数据库(每天一张表),允许简单的数据清理。(这是分区。但是我可以访问的mysql版本(即内部支持的)不支持它)
  • 使用类似couchdb或mongodb的基于文档的数据库(问题可能出在索引/成熟度/摄入速度上)

有什么建议吗?


1
这是一个系统管理员的问题,意味着它应该在姊妹站点“Server Fault” serverfault.com 上发布。 - tylerl
2
不是很确定,我所询问的答案确实会对开发产生重大影响。 - makapuf
5个回答

8
(免责声明:我在MongoDB工作。)
我认为MongoDB是记录日志的最佳解决方案。它非常快,可以比你发送数据更快地插入数据。您可以对数据执行有趣的查询(例如日期范围或日志级别),并索引和字段或字段组合。它还很好,因为您可以随机添加更多的日志字段(“哎呀,我们想要一些堆栈跟踪字段”),而不会导致问题(与平面文本文件相同)。
就稳定性而言,许多人已经在生产中使用MongoDB(请参见http://www.mongodb.org/display/DOCS/Production+Deployments)。在我们进入1.0之前,我们只需要添加更多功能即可。

4

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

我不明白为什么你需要数据库。似乎你只需要扫描数据即可。将日志保留在最“原始”的状态,然后处理它,每天创建一个tarball文件。

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


2
我建议每次上传一个文件,并按你最初的建议每天创建一个目录。在一天结束时,对文件进行处理,然后对目录进行tar.bz2压缩。
tarball仍然可以被搜索,并且由于日志通常可以很好地压缩,所以它可能非常小。
对于总数据量,您每天需要处理1GB [更正为10MB]未压缩的数据。这通常可以压缩到100MB或更少。我使用bzip2对我的日志文件进行200倍的压缩。您可以轻松地将已压缩的数据存储在文件系统上多年而不必担心任何问题。如果需要进行其他处理,可以编写脚本来搜索压缩的tarball并生成更多统计信息。

你所说的是每天10MB未压缩的数据量吗?不,那是每天10万行代码(10k用户10个文件100行)的数量。如果一行代码大约100字节,那么每天的数据量将超过1GB。 - makapuf

1

由于您想要存储它们以便能够每晚计算杂项统计信息,导出它们(按到达日期或第一行内容排序)...您预计每天会有100,000个文件,总共10,000,000行:

我建议:

  1. 使用以下格式将所有文件存储为常规文本文件:yyyymmdd/producerid/fileno。
  2. 在一天结束时,清除数据库,并加载当天的所有文本文件。
  3. 加载文件后,可以轻松从数据库中获取统计信息,并以任何所需的格式发布它们。(甚至可以生成另一个“统计”数据库)。您还可以生成图表。
  4. 为了节省空间,您可以压缩每日文件夹。由于它们是文本文件,因此它们会压缩得很好。

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


0
根据我的经验,如果我们谈论数据库解决方案,单个大表的性能要比几个链接表快得多。特别是在写入和删除操作方面。例如,将一个表拆分成三个链接表会使性能降低3-5倍。当数据量变得非常大时,情况会变得更糟。我认为,存储日志数据的最佳方式不是以平面文本的形式,而是以结构化形式,这样您可以稍后进行高效的查询和格式化。管理日志文件可能很麻烦,特别是当它们来自许多来源和位置时。请查看我们的solution,我认为它可以节省您大量的开发时间。

谢谢,但是想法是表不会链接在一起,例如按生产日期分片。因此,对其进行写入只会修改一个表。而按日期删除将被实现为删除表。 - makapuf

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接