目前,我们储存了大量的原木(30g/天x3台机器=av。100克)。原木拉上拉链。搜索该日志的实际工具是搜索相应的日志(根据时间范围),在本地复制它们,解压它们,并在xml中搜索信息和显示。我们正在研究制作一个类似spunk的工具来搜索日志的可能性(它是消息总线的输出:发送到其他系统的xml消息)。依赖mongo-like数据库而不是直接查询压缩的日志文件有什么好处?我们还可以索引数据库中的一些数据,让程序搜索目标zip文件。。。是什么让mongodb。。。还是hadoop更多?
ekqde3dh1#
我曾经在mongodb上工作过,现在正在hadoop上工作,所以我可以列出一些您可能会感兴趣的差异。mongodb需要您将文件存储为文档(而不是原始文本数据)。hdfs可以将其存储为文件,并允许您使用自定义mapreduce程序来处理它们。mongodb将要求您选择一个好的分片密钥,以便在集群中有效地分配负载。因为您正在存储日志文件,所以这可能很困难。如果您可以将格式化的日志存储到mongodb中的文档中,它将允许您在大量日志中以非常低的延迟查询数据。我的上一个项目内置了基于mongodb的日志,与mapreduce分析原始文本日志相比,分析速度非常快。但是伐木必须从头开始。在hadoop中,有hive、hbase和impala等技术可以帮助您分析文本格式日志,但是需要记住mapreduce的延迟(尽管有一些方法可以优化延迟)。总结一下:如果您可以在整个堆栈中实现基于mongodb的日志记录,那么可以使用mongodb,但是如果您已经有文本格式的日志,那么可以使用hadoop。如果您可以将xml数据实时转换为mongodb文档,那么您可以得到一个非常有效的解决方案。
h5qlskok2#
我对hadoop的了解有限,所以我将重点介绍mongodb。您可以将每个日志条目存储在mongodb中。在时间字段上创建索引时,可以很容易地获得特定的时间范围。mongodb将在2.4版中支持全文搜索,这对于您的用例来说无疑是一个有趣的特性,但是它还没有准备好生产。在此之前,搜索子字符串是一个非常缓慢的操作。因此,您必须将与您的搜索相关的xml树转换为mongodb对象,并为搜索最多的字段创建索引。但是您应该知道,在mongodb中存储日志意味着您将需要更多的硬盘空间。mongodb不压缩有效负载数据,还增加了一些自己的元数据开销,因此它需要比解压缩日志更多的磁盘空间。另外,当您使用新的文本搜索功能时,它将占用更多的磁盘空间。在我看到的一次演示中,文本索引的大小是它索引的数据的两倍。当然,这个特性仍在开发中,但我不会打赌它在最终版本中会少很多。
2条答案
按热度按时间ekqde3dh1#
我曾经在mongodb上工作过,现在正在hadoop上工作,所以我可以列出一些您可能会感兴趣的差异。
mongodb需要您将文件存储为文档(而不是原始文本数据)。hdfs可以将其存储为文件,并允许您使用自定义mapreduce程序来处理它们。
mongodb将要求您选择一个好的分片密钥,以便在集群中有效地分配负载。因为您正在存储日志文件,所以这可能很困难。
如果您可以将格式化的日志存储到mongodb中的文档中,它将允许您在大量日志中以非常低的延迟查询数据。我的上一个项目内置了基于mongodb的日志,与mapreduce分析原始文本日志相比,分析速度非常快。但是伐木必须从头开始。
在hadoop中,有hive、hbase和impala等技术可以帮助您分析文本格式日志,但是需要记住mapreduce的延迟(尽管有一些方法可以优化延迟)。
总结一下:如果您可以在整个堆栈中实现基于mongodb的日志记录,那么可以使用mongodb,但是如果您已经有文本格式的日志,那么可以使用hadoop。如果您可以将xml数据实时转换为mongodb文档,那么您可以得到一个非常有效的解决方案。
h5qlskok2#
我对hadoop的了解有限,所以我将重点介绍mongodb。
您可以将每个日志条目存储在mongodb中。在时间字段上创建索引时,可以很容易地获得特定的时间范围。mongodb将在2.4版中支持全文搜索,这对于您的用例来说无疑是一个有趣的特性,但是它还没有准备好生产。在此之前,搜索子字符串是一个非常缓慢的操作。因此,您必须将与您的搜索相关的xml树转换为mongodb对象,并为搜索最多的字段创建索引。
但是您应该知道,在mongodb中存储日志意味着您将需要更多的硬盘空间。mongodb不压缩有效负载数据,还增加了一些自己的元数据开销,因此它需要比解压缩日志更多的磁盘空间。另外,当您使用新的文本搜索功能时,它将占用更多的磁盘空间。在我看到的一次演示中,文本索引的大小是它索引的数据的两倍。当然,这个特性仍在开发中,但我不会打赌它在最终版本中会少很多。