10

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

给 CouchDB 中的每个用户自己的数据库来保存他们的文档是一个好习惯吗？

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

原因：

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

有什么建议么。

先感谢您。

4

4 回答 4

12

为每个用户创建 CouchDB 存储桶 (DB) 是相当常见的场景。虽然有一些缺点：

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

Per-doc read ACL 可以使用_list函数来实现，但是这种方法有一些缺点，并且它还需要在 CouchDB 前面有一个代理，至少是一个 Web 服务器。有关更多详细信息，请参阅CouchDb 使用列表读取身份验证。

您还可以尝试使用实现完整的按文档读取 ACL 的CoverCouch，保持原始 CouchDB API 不变，但它还处于早期测试阶段。

于 2015-02-17T00:23:00.443 回答
3

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

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

请注意，多个数据库的一个缺点是您不能编写跨多个数据库的查询。不过有一些解决方法 - 有关更多信息，请参阅Cloudant：跨数据库搜索。

2017 年 3 月 17 日更新：

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

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

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

于 2015-02-16T11:44:07.157 回答
2

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

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

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

于 2015-02-18T02:56:55.630 回答
1

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

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

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

  1. 只允许通过虚拟主机访问。这可以使用代理来实现，或者更简单地通过使用couchdb 托管服务提供商来实现，它可以让您微调“域-> 路径”映射

  2. 使用设计文档/沙发应用程序，而不是直接文档 CRUD API，进行读/写操作

    2.1。使用_rewrite处理程序仅允许有效请求：通过这种方式，您可以立即阻止对 _all_docs、_all_dbs 等合理处理程序的访问

    2.2. 使用_list和_view处理程序来读取基于文档​​/角色的 ACL，如CouchDb 使用列表读取身份验证中所述

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

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

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

于 2015-02-18T09:51:32.157 回答