mongodb + nodejs保存聊天logging
我正在开发node.js和mongoose聊天系统。 使用mongodb存储整个聊天logging是否很好？ 或者我们应该使用ant替代？
对于我的意见，mongodb不是完美的logging任何东西，因为：
- 你的数据结构（message，userId等）不会被改变
- 你应该以某种方式select它，组，命令等。SQL是更好的
- 通常情况下，日志并不是经常被要求的东西，所以你不需要键入它的值。
- 你会写更多的阅读
在输出项目中，我们将最近的聊天历史logging存储在redis列表（用于快速简单获取）以及postgres中的其他日志中。
好的，我已经使用评论内容稍微转换了一下这个问题：
但是很less有朋友build议最好不要使用增长的mongoDB集合。 这就是为什么有点困惑。 如果你正在做这个项目，你会怎么做？
在有关如何有效地使用MongoDB的build议。
我不确定引用你的朋友引用什么，但MongoDB是非常擅长聊天的应用程序，其初始数据永远不会更新，也就是说你永远不会发送更新语句到服务器，只有一个insert()和一个remove() （可能是一个更新说明什么时候看到，但应该是一个到位更新）。
但是，如果你正在更新行（文档），MongoDB不会那么好，但是在最近的版本中，它们也有了很多改进。 默认情况下引入powerof2sizes意味着，在文档被要求移动到新的磁盘扇区之前，实际上可以将消息增大到接近其原始大小的2 powerof2sizes ，从而使得磁盘的重用也更容易。 对于IO和CPU来说，非内置更新当然是昂贵的。
至于seaching，SQL确实拥有FTS，但是，由于Stack Exchange本身发现：数据库不能很好地search。 他们很快用Elastic Search取代了MS SQL FTS。
至于sorting：我不确定为什么SQL会在这里更好。 MongoDB可以对一个索引进行sorting，在这种情况下，对任何数据库来说，对一个非内存进行sorting都是非常糟糕的做法。 想象一下，不得不从数据库中加载每个注释来进行sorting。 所以在sorting时两者是平等的。
通过分组，MongoDB现在具有聚合框架，但是由于回归，目前缺乏使用覆盖查询的能力。 这意味着一个组将从当前的磁盘加载，而不是只使用一个索引。 这确实使SQL在这方面更好…目前。 然而，我很难看到你如何组织任何事情，你会有两个表：
- 会话
- 消息
一个屏幕显示第一个表格和第二个表格显示…第二个。
您将通过第一个表上的user_id和第二个表上的convo_id进行过滤。
日志是一个聊天应用程序非常普遍的要求，所以不像@Rax我不会在我的理由中使用它; 我不确定如何改变MongoDB和其他技术之间的空间需求。 这就是说：相当多的技术实际上使用默认的MVCC，这会比MongoDB需要更多的空间（需要注意的是，SQL技术并不是很多的数据库，比如聊天公司采用的CouchDB等） 。
我也会说你会读得比你写的更多。 每次有人发送消息都会有一个消息，不仅在原来的一边说“它已经发送!!!” 而且还在接收端说“下一条消息”。 所以每个消息都会触发两倍的读取。 MongoDB适用于这些types的工作stream程。
无论如何，这应该给你一些指针。 我会尝试MongoDB和它如何适用于你。