CouchDB - 移动应用架构 - 复制性能
CouchDB - Mobile application architecture - Replication performance
我基于 CouchDB 构建了一个移动应用程序。
出于安全原因，我必须确保文档只能由允许的用户读取。由于我无法在文档级别管理访问权限，因此我为每个用户创建了一个 couchdb 数据库，并通过过滤复制从每个用户数据库中的主 couchDB 数据库复制了文档。
这个模型工作得很好，但今天我遇到了巨大的性能问题。
我试图让我所有的复制都是连续的、过滤的和双向的，但是在 80 个用户之后（所以 81 个数据库和 160 个同时连续的复制），复制太多了，我的 couchDB 服务开始变慢甚至有时坠毁。注意所有数据库都在同一台服务器上（我不能有超过一台服务器）
我尝试进行 "manual" 复制，但即使这样，当我需要将文档从我的主数据库复制到我所有的 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. 如果现在的架构一点都不好，你建议我用什么样的架构？
非常感谢！
第 0 步始终是确定瓶颈。根据您概述的场景，我的第一个猜测是查看 I/O 性能。查看
GET /_stats/couchdb
和
GET /_active_tasks
每个数据库都有自己的读写文件描述符，因此随着服务器上打开的数据库数量的增加，所需的 I/O 资源也会增加。希望这有帮助
我们终于改变了我们的全球项目架构。
即使可以更改配置限制，主服务器也无法处理超过 100 个复制数据库，在 80 个同步数据库之后，couchdb 日志开始爆炸。我可能错了，但我认为这种架构在单个服务器上是不可能的。
这是我们实施的解决方案。
我们删除了所有用户数据库，并将所有移动应用程序直接插入主数据库，并直接在主数据库上进行过滤复制：http://pouchdb.com/api.html#replication 通过使用此解决方案：示例 3：设计文档中的过滤功能
这个新模型现在可以正常工作我们做了一些压力测试，直到 1000 个并发用户时我们才发现任何问题。
请注意 pouchDB，要复制数据库，请询问 couchdb 自上次同步以来应用于主数据库的所有修改（即使是过滤复制）。所以当你创建一个新的 pouchdb 数据库并同步它时，如果你的主 couchDB 很旧并且有很大的历史（检查 couchdb _changes API），它可能需要非常（非常）长的时间！
我基于 CouchDB 构建了一个移动应用程序。
出于安全原因，我必须确保文档只能由允许的用户读取。由于我无法在文档级别管理访问权限，因此我为每个用户创建了一个 couchdb 数据库，并通过过滤复制从每个用户数据库中的主 couchDB 数据库复制了文档。
这个模型工作得很好，但今天我遇到了巨大的性能问题。
我试图让我所有的复制都是连续的、过滤的和双向的，但是在 80 个用户之后（所以 81 个数据库和 160 个同时连续的复制），复制太多了，我的 couchDB 服务开始变慢甚至有时坠毁。注意所有数据库都在同一台服务器上（我不能有超过一台服务器）
我尝试进行 "manual" 复制，但即使这样，当我需要将文档从我的主数据库复制到我所有的 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. 如果现在的架构一点都不好，你建议我用什么样的架构？
非常感谢！
第 0 步始终是确定瓶颈。根据您概述的场景，我的第一个猜测是查看 I/O 性能。查看
GET /_stats/couchdb
和
GET /_active_tasks
每个数据库都有自己的读写文件描述符，因此随着服务器上打开的数据库数量的增加，所需的 I/O 资源也会增加。希望这有帮助
我们终于改变了我们的全球项目架构。 即使可以更改配置限制，主服务器也无法处理超过 100 个复制数据库，在 80 个同步数据库之后，couchdb 日志开始爆炸。我可能错了，但我认为这种架构在单个服务器上是不可能的。
这是我们实施的解决方案。 我们删除了所有用户数据库，并将所有移动应用程序直接插入主数据库，并直接在主数据库上进行过滤复制：http://pouchdb.com/api.html#replication 通过使用此解决方案：示例 3：设计文档中的过滤功能
这个新模型现在可以正常工作我们做了一些压力测试，直到 1000 个并发用户时我们才发现任何问题。
请注意 pouchDB，要复制数据库，请询问 couchdb 自上次同步以来应用于主数据库的所有修改（即使是过滤复制）。所以当你创建一个新的 pouchdb 数据库并同步它时，如果你的主 couchDB 很旧并且有很大的历史（检查 couchdb _changes API），它可能需要非常（非常）长的时间！