2

我正在开发一个包含两种类型数据的应用程序：

1) 用户配置文件 - 用户名、电子邮件、用户 ID、访问令牌、会话 ID、AvatarUrl 等。对于每个用户，此数据约为 20kB，对于活动用户，数据将被读取 100 次/天并写入 5 次/天. 我正在考虑使用 ObjectRocket (MongoDB) 或 Cloudant (CouchDB with Clustering) --- 我喜欢 Cloudant 的极端容错性（主/主复制、仅崩溃设计和 Cloudant 的多地理冗余），但我担心如此多的文档修订将非常快地占用磁盘空间，并且整体性能不如 MongoDB。我正在学习 MongoDB。对这种数据类型有什么建议吗？

2) 用户对用户的交易——用户A向用户B发送8分——检查用户A的积分余额，如果>8，则借记UserA并贷记UserB。每笔交易大约 2kB 并且可能永远不会被更新或删除（会计师不使用橡皮擦）。为此，我正在考虑将 CouchDB (Cloudant) 与 Map/Reduce 视图一起使用，其中视图将跟踪用户余额。这些数据当然对应用程序的完整性极为重要，我认为 Couch 可以让我在晚上睡得更好（尤其是在主/主复制、仅崩溃设计和 Cloudant 的多地理位置冗余的情况下）。对于这种数据类型还有其他建议吗？

总的来说，为了简单起见，我想使用一种 DB 类型，但似乎有时要建房子，你需要一把锤子和一把螺丝刀。对数据类型 #1 使用 Mongo (ObjectRocket) 对数据类型 #2 使用 Couch (Cloudant) 是否有意义？

4

2 回答 2

2

1) 在 Cloudant 上，您无需担心先前编辑的磁盘空间 - 我们会自动触发压缩以在后台清理旧的、非冲突的修订。

2) 可以通过为每个贷方或借方创建一个新文档并使用 map-reduce 视图生成帐户余额，在 CouchDB / Cloudant 中对此进行建模。CouchDB Definitive Guide中有一个完整的例子。您的应用程序逻辑将遵循：

  1. 借记用户A
  2. 断言用户 A 有足够的贷方（例如借方后仍有正余额）
  3. 信用用户B

如果 2 或 3 失败，则记入用户 A 并适当通知。

于 2013-07-22T10:44:02.110 回答
1

1) 在这种情况下，您不会使用太多磁盘空间，因为除非发生冲突，否则旧版本会定期删除，这在这种情况下似乎不太可能。

2）这是您需要事务的地方，而 CouchDB 或 Cloudant 的最终一致性并不适合。我不确定 MongoDB 是否也能提供你需要的东西。这里最安全的选择是关系数据库。

于 2013-07-19T09:01:59.267 回答