CouchDB用于聊天记录持久性和用户统计信息

        是的，CouchDB或Couchbase是合适的。 由于聊天记录需要多次编写，因此我在考虑使编写变得容易的事情：只需删除文档，然后让CouchDB担心将其汇总。在快速的POST中，您可以描述聊天消息，发送消息的人，时间戳，哪个聊天室等。 CouchDB视图排序规则将使单个实体代表其历史数据。例如，如果您想知道用户消息量，则地图函数将发出如下所示的键：

emit([doc.username, doc.year, doc.month, doc.day, doc.hour, doc.minute], 1);

而reduce函数将所有值相加。现在，您可以查询用户的年交易量，

group_level=3&startkey=[\"somebody\",2011,null]&endkey=[\"somebody\",2011,{}]

或（通过增加组级别）每月数量，每日数量，每小时数量等。 注意事项 该技术具有成本和收益。基本的权衡是，更新应该容易，报告应该合理。在您每天进行10,000次更新的示例中，我不停地思考

409 Conflict

拒绝，或者维护冲突解决代码，或者在堆积更多消息时使客户端从错误中正常恢复！ 建议的技术会有所帮助。每个更新与其他更新都是隔离的，更新可能会无序发生，错误恢复也不太糟糕。只需在后台重试几次。 （请注意，我个人是倡导更新应该容易的人，也许我对此有偏见。） 代价是“浪费”磁盘空间，并且检索数据（相对）需要更多的工作。 CouchDB缓慢而浪费，就像卡车缓慢而浪费。实际上，卡车在富裕地区很常见，而在贫困地区却很少见，因为它们是更好的长期交易。从情感上讲，我们看到卡车四处乱窜，吐出黑烟，但从理性上讲，我们知道它们更有效。 大多数统计信息可以是直接的地图/缩小视图。但是，您也可以维护具有汇总或独立结果的“摘要”文档，或者您需要的其他任何文档。频繁的更新不是问题（在这个规模上：每天86,400个更新仍然仅为1 /秒）。但是您可能需要一个专用的“ updater”客户端来处理这些文档。仅由一个客户端来更新特殊文档，您将不会得到2分，因为没有其他人在争取更新同一文档。