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

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

| CouchDB或CouchBase是否适合作为基于NoSQL的持久性解决方案来存储用户聊天记录和统计信息？由于聊天历史可能需要写入而不是读取具有某些统计信息的单个用户历史记录的文档结构，因此，单个实体代表用户具有嵌入的或分离的历史数据文档（很多小文档）和一些统计信息（少量文档）？     

解决方法

        是的，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\",{}]

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

409 Conflict

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