couchdb - 是否有许多设计文档使 Couchdb 陷入困境？

Question

我的公司正在使用 CouchDB，我很快就必须与它进行交互，所以我正在参加一个速成类(class)，当我阅读各种教程和示例时，我遇到了一个令人惊奇的问题:做很多设计文档都让 CouchDB 陷入困境？

我读到的具体示例反射(reflect)了我自己的用例，其中中间层为每个客户创建一个新的设计文档，将所有查询和相关生成的 b 树限制为该客户。

但这是否意味着在最佳情况下(从业务角度来看)您将拥有数千个设计文档？我突然想到，因为这些设计文档中的每一个都必须为每个插入运行，如果只是不发出任何东西，那最终会给服务器带来很大的压力。

我是否遗漏了 CouchDB 设计的一些重要内容，使这不是问题？或者有没有更聪明的方法来处理这个问题？

Answer 1

我可能不会推荐这种方法。让我们考虑一些情况:
新客户
您将创建一个新的设计文档，并将其添加到您的数据库中。在这种情况下，当从该设计文档请求第一个 View 时，它将遍历数据库中的所有文档以创建索引。因此，每个新客户都会扫描所有文档。
新记录/或记录更改
所有其他文档更改都将通过所有设计文档 View 功能运行。
选择
为每个客户创建一个数据库。每个数据库中有一个设计文档。有一个用于聚合的主数据库，所有客户数据库都复制到该数据库。