我目前正在考虑在我要编写的下一个应用程序中使用CouchDB 2和PouchDB 7。基本上，我将在中央存储中拥有一个CouchDB，Web客户端和移动应用程序将启动一个具有思考能力的PouchDB。基本上，这就像一种魅力。
但是...如果应该根据文档所有权进行过滤，我该如何在CouchDB和PouchDB之间进行过滤同步？
我了解每个用户数据库的解决方案。但是我的文档将由文档的创建者和他/她作为读者或作家添加的人员共享访问权限。
2018年是否有解决此问题的解决方案？早在2016年，我无法解决此问题，因此放弃了该应用程序的构想。
答案 0 :(得分：3)
您应在文档中包含限制访问文档，所有权，授权用户所需的信息。
基于此信息，CouchDB和PouchDB之间有两个用于筛选复制定义的选项（检查筛选选项）。
基于CouchDB设计文档中定义的JavaScript过滤器功能。 Filter functions允许您实现过滤逻辑，该过滤逻辑接受请求期间提供的参数作为URL参数，或者接受通过req参数在CouchDB中进行身份验证的用户。
这种方法的主要问题是，只要数据库增长，您就会注意到性能下降。过滤器将应用于数据库中的每个文档，甚至删除文档，以产生结果。因此，如果您预见到数据库中将有大量文档，那么我不建议您使用这种过滤机制。这里有这种problems的示例。
对该性能问题的一个轻微改进是用Erlang编写了过滤逻辑，该过滤逻辑比JS选项要复杂一些，在测试期间，我并没有从中获得很大收益。
在CouchDB 2.x中，可以选择使用selectors执行过滤复制。可以为选择器编制索引，并且报告说比JS过滤器快10倍。选择器完全由客户端定义，并不基于数据库中的身份验证上下文。此选项的扩展性比上一个更好。
无论如何，过滤允许您在复制过程中进行一些数据库分段，但这不是文档级读取权限的安全机制。
可以使用validate document update functions获得文档写入权限。
我用9000个文档加载了数据库，并使用以下三种技术对_changes提要过滤进行了时间测量：JS过滤，Erlang过滤，Mango选择器过滤和Doc id过滤，结果如下：
该测试确认JS过滤是最差的选择，因为它需要在外部过程中评估过滤条件，这会带来额外的开销。在过滤过程中评估Erlang和Mango表达式，这代表了实际的性能提升。
为了验证文档数量对过滤的影响，我创建了一个包含20.000个文档的数据库，并且执行了相同的测试，结果如下：
JS，Erlang和Mango过滤的时间增量与文档数成线性关系。这些过滤机制未使用任何索引。文档ID过滤是恒定的，因为它基于_id索引。