代码之家  ›  专栏  ›  技术社区  ›  Ankur Gupta

存储数百万个日志文件—每年约25 TB

  •  7
  • Ankur Gupta  · 技术社区  · 15 年前

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

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

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

    安克尔

    5 回复  |  直到 15 年前
        1
  •  4
  •   RameshVel    15 年前

    因为您不需要查询功能,所以可以使用 apache hadoop .

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

    powered by 页

        2
  •  3
  •   Jim Ferrans    15 年前

    看看 Vertica ,一个支持并行处理和快速查询的柱状数据库。康卡斯特用它来 analyze about 15GB/day of SNMP data

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

        3
  •  3
  •   Nauman    15 年前

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

    http://www.gluster.org/

        4
  •  3
  •   Spike Gronim    15 年前

    对于这些数据(mongo、cassandra等),我强烈反对使用键/值或基于文档的存储。使用文件系统。这是因为文件太大,访问模式将是线性扫描。您将遇到的一个问题是保留。大多数“NoSQL”存储系统使用逻辑删除,这意味着您必须压缩数据库以删除删除的行。如果您的单个日志记录很小,并且您必须对它们中的每一个进行索引,那么您也会遇到问题—您的索引将非常大。

    将数据放在HDFS中,以64 MB的数据块进行2-3路复制,格式与现在相同。

        5
  •  0
  •   Jim Ferrans    15 年前

    在CouchDB上,您可以使用_AttachementAPI将文件按原样附加到文档,文档本身只能包含用于索引的元数据(如时间戳、位置等)。然后,您将拥有一个用于文档和附件的RESTAPI。

    Mongo的GridFs也可以采用类似的方法,但您可以自己构建API。