nosql - 用于聊天历史持久化和用户统计的 CouchDB

Question

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

Answer 1

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

或者(通过增加组级别)月量、日量、小时量等

注意事项

这项技术有成本也有好处。基本的权衡是，更新应该容易，报告应该合理。在您每天 10,000 次更新的示例中，想到 409 Conflict 拒绝、维护冲突解决代码或让客户端在更多消息堆积时从错误中正常恢复，我感到紧张!

建议的技术有帮助。每个更新都与其他更新隔离，更新可以乱序发生，错误恢复也不错。只需在后台重试几次即可。 (请注意，我个人是 updates should be easy 的拥护者——也许我有偏见。)

成本是“浪费”磁盘空间，检索数据是(相对)更多的工作。 CouchDB 缓慢而浪费，就像卡车缓慢而浪费一样。实际上，货车在富裕地区很常见，而在贫困地区并不常见，因为它们是一项更好的长期交易。在情感上，我们看到卡车缓慢行驶并吐出黑烟，但在理性上，我们知道它们效率更高。

大多数统计数据可以是直接映射/缩减 View 。但是，您还可以维护包含聚合或独立结果的“摘要”文档，或者您需要的任何其他内容。频繁更新不是问题(在这个规模上:每天 86,400 次更新仍然只是 1 次/秒)。但是您可能需要一个专门用于这些文档的“更新程序”客户端。只有一个客户端在更新特殊文档，你不会得到 409 Conflict，因为没有其他人在更新同一个文档。