为每个CouchDB用户提供一个单独的数据库是一种好习惯吗？

Question

我对用户及其文档的结构有一些概念性问题。

为CouchDB中的每个用户提供一个保存文档的数据库是一种好习惯吗？

我已经读过，couchDB可以处理数千个数据库，并且每个用户拥有自己的数据库并不罕见。

原因：

提出这个问题的原因是我正在尝试创建一个系统，其中登录用户只能查看自己的文档而无法查看任何其他用户文档。

任何建议。

提前谢谢。

Answer 1

为每个用户创建CouchDB存储桶（DB）是相当常见的情况。虽然有一些缺点：

• 您必须在每个用户存储桶中保持ddoc同步，因此在多个存储桶中部署ddoc更改可能会成为一次真正的冒险。
• 如果以某种方式在用户之间共享文档，则会在每个存储桶中获得doc和viewindex dupes。
• 您必须阻止_info请求以避免用户列表泄漏（或者您必须使用哈希命名存储桶）。
• 在任何情况下，您都需要在Couch面前使用一些代理来创建和准备用户注册的新存储桶。
• 当收到许多请求时，你最好保护Couch不会耗尽容量 - 它还需要代理。

Per-doc读取ACL可以使用_list函数实现，但是这种方法有一些缺点，它还需要在CouchDB前面使用代理，至少需要一个Web服务器。有关详细信息，请参阅CouchDb read authentication using lists。

此外，您可以尝试使用CoverCouch来实现完整的每个文档读取ACL，保持原始的CouchDB API不受影响，但它还处于早期测试阶段。

Answer 2

这是一个非常常见的用例，特别是在移动环境中，每个用户的数据都使用Android，iOS或JavaScript（pouchdb）库之一同步到设备。

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

请注意，多个数据库的一个缺点是您无法编写跨多个数据库的查询。但是有一些解决方法 - 有关更多信息，请参阅Cloudant: Searching across databases。

---

2017年3月17日更新：

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

  

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

     

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

Answer 3

解决方案与Web应用程序一样久 - 如果您想到mySQL数据库，数据库中没有任何内容可以阻止用户B查看属于用户A的记录 - 它全部在应用程序层中编码。

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

如果您在CouchDB和用户之间有Web应用程序，那么您没有问题。当您允许CouchDB直接提供请求时会出现问题。

Answer 4

为多个用户使用多个数据库有一些重要的缺点：

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

这取决于您的用例，但我认为一个不错的方法可以是：

1. 仅允许通过虚拟主机访问。这可以通过代理实现，或者更简单地通过使用couchdb hosting提供商来实现，该提供商可以让您微调“域 - ＆gt;路径”映射

2. 使用设计文档 / couchapps ，而不是直接文档CRUD API，用于读/写操作

   2.1。使用 _rewrite 处理程序只允许有效请求：通过这种方式，您可以立即阻止访问_all_docs，_all_dbs等其他敏感处理程序

   2.2。使用 _list 和 _view 处理程序处理读取基于文档​​/角色的ACL ，如CouchDb read authentication using list

   中所述

   2.3。使用 _update 处理程序来编写基于文档/角色的ACL

   2.4。对基于读/写角色的ACL 使用经过身份验证的重写规则。

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