CouchDB或CouchBase是否适合作为基于NoSQL的持久性解决方案来存储用户的聊天记录和统计数据？由于聊天历史记录可能需要写入而不是读取具有某些统计信息的单个用户历史记录的文档结构 - 单个实体表示具有用于历史数据（大量小文档）的嵌入或分离文档的用户以及一些统计信息（少数文档）？
答案 0 :(得分：3)
是的，CouchDB或Couchbase是合适的。
由于聊天记录需要多次写入，我正在考虑使写入变得简单的事情：只需删除文档并让CouchDB担心汇总它。在一个快速POST中，您可以描述聊天消息，发送者，时间戳，聊天室等等。
CouchDB view collation将使单个实体代表用户的历史数据。例如，如果您想知道用户消息量，您的map函数将发出如下所示的键：
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,{}]
或（通过提高小组水平）每月交易量，每日交易量，每小时交易量等
这种技术具有成本和收益。基本的权衡是，更新应该 easy ，报告应该合理。在每天10,000次更新的示例中，我会紧张地考虑409 Conflict拒绝，或维护冲突解决代码，或者让更多邮件堆积时客户端从错误中正常恢复！
建议的技术有帮助。每个更新都与其他更新隔离，更新可能无序发生，错误恢复也不算太糟糕。只需在后台重试几次即可。 （注意，我个人是updates should be easy的倡导者 - 也许我有偏见。）
成本是“浪费”磁盘空间，检索数据是（相对）更多的工作。 CouchDB缓慢且浪费，就像卡车一样缓慢且浪费。实际上，卡车在富裕的地方很常见，在贫穷的地方不常见，因为它们是一种更好的长期交易。在感情上，我们看到卡车笨拙并吐出黑烟，但理性地说，我们知道它们更有效率。
大多数统计信息可以是直接映射/缩小视图。但是，您也可以使用汇总或独立结果或其他任何需要维护“汇总”文档。频繁更新不是问题（在这个规模上：每天86,400次更新仍然只有1次/秒）。但是您可能需要为这些文档提供专用的“更新程序”客户端。只有一个客户端正在更新特殊文档，您将无法获得409 Conflict，因为没有其他人在努力更新同一文档。