给每个CouchDB用户一个单独的数据库是好的做法吗?

为每个用户创建CouchDB存储桶(DB)是非常常见的场景。尽管存在一些缺点:

• 您必须在每个用户存储桶中保持ddoc同步,因此跨多个存储桶部署ddoc更改可能会成为一项真正的冒险。
• 如果文档以某种方式在用户之间共享,则每个存储桶中都会出现文档和视图索引重复。
• 您必须阻止 _info 避免用户列表泄漏的请求(或者必须使用散列来命名桶)。
• 在任何情况下,您都需要在Couch前面安装一些代理,以便在用户注册时创建和准备一个新的bucket。
• 当Couch收到许多请求时,您可以更好地保护它,使其不会耗尽容量,因为它还需要代理。

每个文档读取ACL可以使用 _list 功能,但这种方法有一些缺点,而且它还需要在CouchDB前面有一个代理,至少是一个web服务器。看见 CouchDb read authentication using lists 了解更多详情。

你也可以试着玩 CoverCouch 它实现了一个完整的每文档读取ACL,保持了原始的CouchDB API不变,但它处于很早的测试阶段。

这是一个非常常见的用例,尤其是在移动环境中,每个用户的数据都使用Android、iOS或JavaScript(pouchdb)库之一同步到设备。

所以在概念上,这是可以的,但我仍然建议在投入生产之前进行彻底测试。

请注意,多个数据库的一个缺点是您无法编写跨多个数据库查询。不过,有一些变通办法-有关更多信息,请参阅 Cloudant: Searching across databases .

2017年3月17日更新 :

请查看Cloudant Envoy以了解有关此方法的更多信息。

每个用户的数据库是CouchDB的一种常见模式,当每个应用程序用户都需要有自己的一组可以同步的文档(例如,移动设备或浏览器)时。从表面上看,这是一个很好的解决方案——Cloudant可以很好地处理单个安装中的大量数据库。然而

资料来源: https://github.com/cloudant-labs/envoy

该解决方案与web应用程序一样古老-如果您想到mySQL数据库,数据库中没有任何内容可以阻止用户B查看属于用户a的记录-它都是在应用程序层中编码的。

在CouchDB中,同样没有完全安全的方法来阻止用户B访问用户A编写的文档。您需要像以前一样在应用程序层中对此进行编码。

如果你在CouchDB和用户之间有一个web应用程序,你就没有问题了。当您允许CouchDB直接服务请求时,就会出现问题。

对多个用户使用多个数据库有一些重要缺点:

• 使用本机couchdb API无法查询不同数据库中的数据。 分析你的网站整体状态是不可能的!
• 维护很快就会变得非常困难 :让我们考虑在每次执行备份时复制/压缩数千个数据库

这取决于您的用例,但我认为一个好的方法可以是:

1. 仅允许通过虚拟主机进行访问 。这可以使用代理实现,或者更简单地通过使用 couchdb hosting 提供程序,允许您微调“域->路径”映射

2. 使用 设计文档 / 长沙发 ,而不是直接文档CRUD API,用于读/写操作

   2.1.使用 _重写 仅允许有效请求的处理程序:通过这种方式,您可以立即阻止对合理的处理程序(如all_docs、all_dbs等)的访问

   2.2.使用 _列表 和 _视图 的处理程序 读取基于文档/角色的ACL 如中所述 CouchDb read authentication using list

   2.3.使用 _更新 的处理程序 写入基于文档/角色的ACL

   2.4.使用经过验证的重写规则 基于角色的ACL读/写 .

   2.3. 已过滤的 _变更 处理器 是使用基于读取文档/角色的ACL检索所有用户数据的另一种方法。根据您的用例 可以尽可能有效地简化您的阅读API ,让您专注于更新API。