我正在编写一个带有nodeJS的Web应用程序，其他应用程序可以使用它来存储日志，稍后可以在Web界面中访问，也可以由提供API的应用程序本身访问。与Graylog2类似，但架构免费。
我已经尝试过couchDB，其中每个文档都是一个日志文档，但由于我没有真正使用修订版，所以在我看来我并没有使用它的所有功能。除此之外，我认为如果日志超出限制，那么在couchDB中管理将非常困难。
我真正想要的是一大堆日志，可以对其进行排序，过滤，搜索和封顶。然后访问它的最后一个事件。它应该是无架构的，写入它应该是非阻塞的。
我正在考虑使用Cassandra（我真的不熟悉它），因为here分。 MongoDB在这里似乎也很好，因为Graylog2在mongoDB中使用，在here中它有一些关于它的好点。
我已经看过this个问题，但对答案不满意。
编辑： 出于某些原因，我不能在生产中使用Cassandra，现在我正在尝试使用MongoDB。
使用mongoDB的另一个原因： http://www.slideshare.net/WombatNation/logging-app-behavior-to-mongo-db
更多编辑：
它类似于graylog2，但我想要的不同之处在于，而不是有一个消息字段，有客户端定义的文件，这就是为什么我希望它没有架构，因此，我可能需要在用户定义的字段中查询。我们可以在SQL上构建它，但查询用户定义的字段将重新发明轮子。文件也一样。
从技术上讲，我正在寻找的是最终获得丰富的统计数据，或者简单的调试以及我们无法从日志中获取的许多其他内容。
答案 0 :(得分：3)
在哪里存储以及如何检索？
我想这取决于你要处理的数据量。如果你有大量的日志（每天太字节和千兆字节），那么Apache Kafka（旨在允许HDFS并行提取数据）是一个有趣的解决方案 - 仍处于孵化阶段。我相信如果您想使用MongoDb消费Kafka消息，您需要开发自己的适配器以将其作为特定Kafka主题的消费者来摄取。虽然MongoDb数据（例如，分片和副本）是分布式的，但它可能是一个摄取每个消息的顺序过程。因此，根据消息流量的速率和大小，可能存在瓶颈甚至竞争条件。 Kafka经过优化，可以使用消息代理FAST将数据泵送并附加到HDFS节点。然后，一旦它在HDFS中，您可以映射/缩小以便以各种方式分析您的信息。
如果MongoDb可以处理摄取负载，那么它是一种优秀的，可扩展的实时解决方案，可以查找信息，尤其是文档。否则，如果您有更多时间处理数据（即批量处理需要数小时甚至数天），则需要Hadoop或其他Map Reduce数据库。最后，Kafka可以将这些消息和连接消息分发给各种消费者。总体而言，这些新技术使用软件在廉价硬件上分散负载和大量数据，以便以极低的丢失数据概率来管理故障和恢复。
即使只有少量数据，MongoDb也是传统关系数据库解决方案的一个不错的选择，它需要更多的开发人员资源开销来设计，构建和维护。
答案 1 :(得分：2)
你有很多工作要做。无论使用哪种数据库，您都必须在数据库基础之上构建许多功能。您已经对所有选项进行了很好的研究。听起来你怀疑所有人都有利有弊，但都不完美。你的怀疑是正确的。此时可能是开始编写代码的时候了。
您可以随意选择一个并开始构建您的应用程序。如果你的猜测是正确的，利弊平衡，而且一切都差不多，那么为什么不立即开始建设呢？当你在数据库中遇到难度X时，请记住它给你带来了方便的Y和Z，这就是生活。
您还可以建立应用程序的基础核心，并在每个数据库上实现各种原型。这可能会为您提供真正的洞察力，帮助您区分特定应用程序的数据库。例如，除了接口，索引和查询问题之外，部署还有什么？备份怎么样？那么维护和安全呢？也许“浪费”时间在每个平台上构建相同的原型将使您的答案非常明确。
如果你这么说，我认为CouchDB是“NoSQL”。其他“无SQL”的东西包括香蕉，诗歌和板球。这不是一个非常有意义的词。我们有通用语言和特定领域的语言;类似地，CouchDB是特定于域的数据库。如果您需要以下功能，它可以节省您的时间：
答案 2 :(得分：2)
您考虑过Apache Kafka了吗？
Kafka是一个在LinkedIn上开发的分布式消息传递系统 以低延迟收集和提供大量日志数据。 我们的系统融合了现有日志聚合器和创意 消息传递系统，适用于离线和在线消息 消耗。