我应该使用哪个NoSQL数据库进行日志记录？

Question

您是否有任何使用NoSQL数据库登录可扩展应用程序的经验？我已经对NoSQL数据库做了一些关于日志记录的研究,发现MongoDB似乎是一个不错的选择.另外,我发现log4mongo-net似乎是一个非常简单的选择.

你会推荐这种方法吗？还有其他建议吗？

Answer 1

我决定修改这个被接受的答案,因为在过去的18个月中,最先进的技术已经发生了很大变化,并且存在更好的替代方案.

新答案

MongoDB是可扩展日志记录解决方案的次要选择.通常有这样的原因(例如,在负载下写入性能).我想再提出一个,它只能解决日志记录解决方案中的单个用例.

强大的日志记录解决方案至少需要涵盖以下几个阶段:

MongoDB作为一种选择只能解决存储用例(尽管有点差).分析完整的链后,就会有更合适的解决方案.

@KazukiOhta提到了一些选择.我最喜欢的端到端解决方案包括:

ElasticSearch用于日志数据存储的基础使用当前最佳的NoSQL解决方案用于日志记录和搜索用例.事实上,Logstash-Forwarder/Logstash/ElasticSearch/Kibana3属于ElasticSearch的范畴,这使得一个更具说服力的论点成为可能.

由于Logstash也可以充当Graphite代理,因此可以为收集和分析度量(而不仅仅是日志)的相关问题构建非常相似的链.

老答案

MongoDB 上限集合非常受欢迎,适合日志记录,还有"模式少"的额外好处,这通常是一种适合日志记录的语法.通常我们只知道我们想要很好地记录到项目中,或者在生产中发现某些问题之后.在这些情况下,关系数据库或严格模式往往难以改变,并且使它们"灵活"的尝试往往只是使它们"慢"且难以使用或理解.

但是,如果你想在黑暗中管理你的日志,并且让它看起来像是来自太空,那么总是使用MongoDB作为其整体基础设施的一部分的Graylog2,但提供了更多的东西,如a通用,可扩展的格式,专用的日志收集服务器,分布式架构和时髦的UI.

正如警告一样,我们在每秒写入超过几千个事件来记录集合时遇到了MongoDB的严重问题.MongoDB拙劣的写入性能可能是罪魁祸首. (3认同)
关于 Graylog2，请注意：“全部运行在数据中心现有的 JVM 上。” 如果您错过了这一点，那么您将看不到任何内容，直到您查看下载包的安装说明的第三段或第四段（“您还必须使用 Java 7！”）。我一直认为基于 Java 的项目在推销自己时很容易忘记提及它们是基于 Java 的项目，这有点有趣。只是国际海事组织。 (2认同)
有一些 Elasticsearch 丢失数据的例子，尽管我们在实现中没有看到这种情况发生。如果需要真正的审计功能，我会使用双重方法，将*原始*文件保存到（例如）HDFS 进行存档，并将它们发送到 Elasticsearch 进行实时索引和搜索。如果需要，存档可用于协调或重新加载 Elasticsearch 索引。 (2认同)

Answer 2

我见过很多公司都在使用MongoDB来存储应用程序日志.它的模式免费对于应用程序日志非常灵活,而模式往往会随时更改.此外,它的Capped Collection功能非常有用,因为它会自动清除旧数据以使数据适合内存.

人们通过普通的分组或MapReduce聚合日志,但速度并不快.特别是MongoDB的MapReduce仅在单个线程中工作,其JavaScript执行开销很大.新的聚合框架可以解决这个问题.

当您使用MongoDB进行日志记录时,关注的是高写入吞吐量的锁争用.尽管默认情况下MongoDB的插入是fire-and-forget样式,但调用大量的insert()会导致严重的写入锁争用.这可能会影响应用程序性能,并阻止读者聚合/过滤存储的日志.

一种解决方案可能是使用日志收集器框架,如Fluentd,Logstash或Flume.这些守护进程应该在每个应用程序节点上启动,并从应用程序进程获取日志.

流利加上MongoDB

它们缓冲日志并异步地将数据写入其他系统,如MongoDB/PostgreSQL /等.编写是通过批处理完成的,因此它比直接从应用程序编写更有效.此链接描述如何将日志从PHP程序放入Fluentd.

这里有一些关于MongoDB + Fluentd的教程.

MongoDB的问题是,当数据量超过内存大小时,它开始减速.此时,您可以切换到Apache Hadoop或Cassandra等其他解决方案.如果您有上面提到的分布式日志记录层,您可以在增长时立即切换到另一个解决方案.本教程介绍如何使用Fluentd将日志存储到HDFS.