7

作为我工作的一部分，我们每年获得大约 25TB 的日志文件，目前它保存在基于 NFS 的文件系统上。有些以 zipped/tar.gz 格式存档，而另一些则以纯文本格式保存。

我正在寻找使用基于 NFS 的系统的替代方案。我查看了 MongoDB、CouchDB。它们是面向文档的数据库这一事实似乎使其成为合适的选择。但是，日志文件内容需要更改为 JSON 才能存储到数据库中。我不愿意做的事情。我需要按原样保留日志文件内容。

至于使用，我们打算放置一个小的 REST API，并允许人们获取文件列表、最新文件以及获取文件的能力。

提议的解决方案/想法需要是某种形式的分布式数据库或应用程序级别的文件系统，其中可以存储日志文件并可以通过添加更多机器来有效地水平扩展。

安库尔

4

5 回答 5

4

由于您不想查询功能，因此可以使用apache hadoop。

我相信HDFS和HBase会很适合这个。

你可以在 Hadoop 中看到很多巨大的存储故事，由page提供支持

于 2010-10-11T07:28:40.903 回答
3

看看Vertica，一个支持并行处理和快速查询的列式数据库。Comcast 使用它分析了大约 15GB/天的 SNMP 数据，平均每秒运行 46,000 个样本，使用五个四核 HP Proliant 服务器。几周前，我听说一些康卡斯特运营人员对 Vertica 赞不绝口。他们仍然非常喜欢它。它有一些不错的数据压缩技术和“k-安全冗余”，因此它们可以省去 SAN。

更新：可扩展分析数据库方法的主要优点之一是您可以对日志进行一些非常复杂的准实时查询。这可能对您的运营团队非常有价值。

于 2010-10-09T06:40:14.230 回答
3

我强烈反对使用键/值或基于文档的存储来存储这些数据（mongo、cassandra 等）。使用文件系统。这是因为文件太大了，访问模式将是线性扫描。您将遇到的一件事是保留。大多数“NoSQL”存储系统使用逻辑删除，这意味着您必须压缩数据库以删除已删除的行。如果您的个人日志记录很小并且您必须为每个日志记录编制索引，您也会遇到问题 - 您的索引将非常大。

将您的数据以与现在相同的格式以 64 MB 块的 2-3 路复制方式放入 HDFS。

于 2010-10-13T17:16:38.557 回答
3

你试过看gluster吗？它是可扩展的，提供复制和许多其他功能。它还为您提供标准文件操作，因此无需实现另一个 API 层。

http://www.gluster.org/

于 2010-10-12T18:24:19.010 回答
0

如果要选择文档数据库：

在 CouchDB 上，您可以使用 _attachement API 将文件按原样附加到文档中，文档本身只能包含用于索引的元数据（如时间戳、位置等）。然后，您将拥有文档和附件的 REST API。

Mongo 的 GridFs 也可以使用类似的方法，但您需要自己构建 API。

HDFS也是一个非常不错的选择。

于 2010-10-13T19:53:16.837 回答