CouchDB - 移动应用程序架构 - 复制性能答案

【问题标题】：CouchDB - Mobile application architecture - Replication performanceCouchDB - 移动应用程序架构 - 复制性能
【发布时间】：2016-01-09 16:35:27
【问题描述】：

我基于 CouchDB 构建了一个移动应用程序。

出于安全原因，我必须确保文档只能由允许这样做的用户读取。由于我无法在文档级别管理访问权限，因此我为每个用户创建了一个 couchdb 数据库，并通过过滤复制从我的主 couchDB 数据库中复制每个用户数据库中的文档。

这个模型工作得很好，但是今天我遇到了巨大的性能问题。

我试图让我的所有复制都是连续的、过滤的和双向的，但是在 80 个用户（所以 81 个数据库和 160 个同时连续复制）之后，复制太多了，我的 couchDB 服务开始变慢，有时甚至崩溃.注意所有数据库都在同一台服务器上（我不能有多个服务器）

我尝试进行“手动”复制，但即使这样，当我需要将文档从我的主数据库复制到所有 80 个用户数据库时，从我的主数据库到用户数据库的每个过滤复制都会占用30 秒。

也许我的复制过滤器有问题，我为每个文档存储了一个允许查看它的用户列表。由于每个用户都有自己的数据库，我只复制允许用户在其数据库中查看的文档。这是我的复制功能：

function(doc, req) {
  if(doc.userList) {
    if(doc.userList.indexOf(req.query.username) > 1) {
      return true;
    }
  }
  return false;
}

我的应用程序的目标是获得大约 1000 个用户，这在当前架构/性能下是完全不可能的。

我有三个问题： 1.即使我认为不可能，是否可以在同一台服务器上连续复制大约1000个数据库？ 2. 我的复制过滤器有什么问题吗？有什么方法可以改进它以实现快速的数据库复制？ 3. 如果目前的架构一点都不好，你会建议我用什么样的架构？

非常感谢！

【问题讨论】：

看看github.com/ermouth/covercouch

标签： performance couchdb replication

【解决方案1】：

第 0 步始终是识别瓶颈。根据您概述的场景，我的第一个猜测是查看 I/O 性能。退房

GET /_stats/couchdb

和

GET /_active_tasks

每个数据库都有自己的读写文件描述符，因此随着服务器上打开的数据库数量的增加，所需的 I/O 资源也会增加。希望这会有所帮助

【讨论】：

【解决方案2】：

我们终于改变了我们的全球项目架构。即使可以更改配置限制，主服务器也无法处理超过 100 个复制数据库，在 80 个同步数据库 couchdb 日志开始爆炸之后。我可能错了，但我认为这种架构在单个服务器上是不可能的。

这是我们实施的解决方案。我们删除了所有用户数据库，并将所有移动应用程序直接插入主数据库，并直接在主数据库上进行过滤复制：http://pouchdb.com/api.html#replication 使用此解决方案：示例 3：设计文档中的过滤功能

这个新模型现在正在运行，我们进行了一些压力测试，直到 1000 个同时用户才出现任何问题。

请注意，要复制数据库，pouchDB 会询问 couchdb 自上次同步以来应用于主数据库的所有修改（即使对于过滤复制）。因此，当您创建一个新的 pouchdb 数据库并对其进行同步时，如果您的主 couchDB 很旧并且有很大的历史记录（检查 couchdb _changes API），则可能需要非常（非常）长的时间！

【讨论】：