用于聊天历史持久性和用户统计的 CouchDB答案

【问题标题】：CouchDB for chat history persistence and user statistics用于聊天历史持久性和用户统计的 CouchDB
【发布时间】：2011-06-14 19:34:21
【问题描述】：

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

【问题讨论】：

标签： nosql persistence couchdb couchbase

【解决方案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 既慢又浪费，就像卡车又慢又浪费一样。实际上，卡车在富裕的地方很常见，在贫穷的地方很少见，因为它们是一个更好的长期交易。在情感上，我们看到卡车在路上蹒跚而行并吐出黑烟，但在理性上，我们知道它们更有效率。

大多数统计数据可以直接映射/减少视图。但是，您也可以维护具有聚合或独立结果的“摘要”文档，或者您需要的任何其他内容。频繁更新不是问题（在这个规模上：每天 86,400 次更新仍然只是 1/秒）。但是您可能需要一个专门用于这些文档的“更新程序”客户端。只有一个客户在更新特殊文档，您不会收到409 Conflicts，因为没有其他人在努力更新同一个文档。

【讨论】：

如果每个聊天消息都被表示为一个独立的文档，这些文档不会很快占用磁盘空间（假设我们每天谈论大约 10k 条消息）？还可以将用户统计信息存储在单个文档中，其中嵌入的文档代表将经常更新的特定统计信息？
CouchDB 在磁盘上的效率不是很高。原因是，使用额外的磁盘空间使开发更容易。 “当开发人员花费 x 美元时，谁在乎 GB？”无论如何，我有两个数据库，大约 10,000 个文档，一个是 44.5MB，另一个是 5.9MB。如果您认为，每天 100MB 的数据和视图，即每年 36.5GB 的存储空间。对我来说，即使是每年 100 或 200GB 的存储空间也没有问题如果数据库正在放松。
我明白你的意思，这是可以接受的。关于存储以用户为中心的统计数据和少量嵌入式文档的单个文档 - 如果该文档将实时频繁更新，这是一个好的“设计”理念吗？
我将编辑答案来讨论这个问题；希望它会比 cmets 更清楚。