作为我工作的一部分，我们每年获得大约25TB的日志文件，目前它是通过基于NFS的文件系统保存的。有些文件存档为zipped / tar.gz，有些则以纯文本格式存档。
我正在寻找使用基于NFS的系统的替代方案。我查看了MongoDB，CouchDB。它们是面向文档的数据库这一事实似乎使它成为合适的选择。但是，日志文件内容需要更改为JSON才能存储到数据库中。我不愿意做的事。我需要按原样保留日志文件内容。
至于使用情况，我们打算放置一个小型REST API，允许人们获取文件列表，最新文件以及获取文件的能力。
建议的解决方案/想法需要是应用程序级别的某种形式的分布式数据库或文件系统，其中可以存储日志文件，并且可以通过添加更多计算机来有效地水平扩展。
ANKUR
答案 0 :(得分：4)
答案 1 :(得分：3)
查看Vertica，一个支持并行处理和快速查询的柱状数据库。 Comcast使用它来analyze about 15GB/day of SNMP data，使用五个四核HP Proliant服务器以平均每秒46,000个样本的速度运行。几个星期前，我听到一些康卡斯特的操作人员对Vertica赞不绝口;他们仍然非常喜欢它。它有一些不错的数据压缩技术和“k-safety冗余”，所以他们可以省去SAN。
更新：可扩展分析数据库方法的主要优势之一是您可以对日志进行一些非常复杂，准实时的查询。这可能对您的运营团队非常有价值。
答案 2 :(得分：3)
你试过看过gluster吗？它具有可扩展性，提供复制和许多其他功能。它还为您提供标准文件操作，因此无需实现其他API层。
答案 3 :(得分：3)
我强烈反对使用基于键/值或基于文档的商店来获取此数据（mongo，cassandra等）。使用文件系统。这是因为文件太大，访问模式将是线性扫描。您将遇到的一个问题是保留。大多数“NoSQL”存储系统使用逻辑删除，这意味着您必须压缩数据库以删除已删除的行。如果您的个人日志记录很小并且您必须为每个记录编制索引，那么您也会遇到问题 - 您的索引会非常大。
将您的数据放入HDFS中，使用与现在相同格式的64 MB块进行2-3路复制。
答案 4 :(得分：0)
如果要选择文档数据库：
在CouchDB上，您可以使用_attachement API将文件原样附加到文档，文档本身只能包含用于索引的元数据（如时间戳，位置等）。然后，您将拥有文档和附件的REST API。
Mongo的GridF可以采用类似的方法，但您可以自己构建API。
HDFS也是一个非常好的选择。