CouchDB 或 CouchBase 是否适合作为基于 NoSQL 的持久性解决方案来存储用户聊天历史和统计信息？由于聊天历史可能需要写入而不是读取具有某些统计信息的单个用户历史记录的文档结构 - 单个实体代表用户，其中嵌入或分离的文档用于历史数据（大量小文档）和一些统计信息（少量文档）？
问问题
1293 次
1 回答
4
是的，CouchDB 或 Couchbase 是合适的。
由于聊天记录需要多次写入，因此我正在考虑使编写变得容易的方法：只需删除一个文档并让 CouchDB 担心聚合它。在一篇快速 POST 中，您可以描述聊天消息、发送者、时间戳、哪个聊天室等。
CouchDB 视图整理将使单个实体代表用户及其历史数据。例如，如果您想知道用户消息量，您的 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拒绝、维护冲突解决代码或在更多消息堆积时让客户端从错误中优雅地恢复时感到紧张！
建议的技术会有所帮助。每个更新都与其他更新隔离，更新可能发生乱序，错误恢复也不错。只需在后台重试几次。（注意，我个人主张更新应该很容易——也许我有偏见。）
代价是“浪费”磁盘空间，检索数据（相对）更多的工作。CouchDB 既慢又浪费，就像卡车又慢又浪费一样。实际上，卡车在富裕的地方很常见，而在贫穷的地方并不常见，因为它们是更好的长期交易。在情感上，我们看到卡车在路上蹒跚而行并吐出黑烟，但在理性上，我们知道它们更有效率。
大多数统计数据可以是直接的 map/reduce 视图。但是，您也可以维护具有聚合或独立结果的“摘要”文档，或者您需要的任何其他内容。频繁更新不是问题（在这个规模上：每天 86,400 次更新仍然只是 1/秒）。但是您可能需要一个专门用于这些文档的“更新程序”客户端。只有一个客户在更新特殊文档，你不会得到409 Conflicts，因为没有其他人在努力更新同一个文档。
于 2011-06-15T09:40:46.173 回答