使用 CouchDB 进行选择性复制
我目前正在评估以下问题的可能解决方案：
一组数据条目必须在多个客户端之间同步，其中每个客户端只能查看（甚至知道其存在）数据的子集。 每个客户端“拥有”一些元素，并且其他人可以读取或修改这些元素的决定只能由所有者做出。为了使这种情况更加复杂，每个元素（以及每个元素修订版）必须具有对所有客户端都相同的唯一标识符。
虽然后者听起来像是 CouchDB 的完美任务（基于文档的数据模型将完全满足我的需求），但我不确定 CouchDB 的身份验证/授权子系统是否可以处理这些要求：虽然应该可以限制写入使用验证功能进行访问，似乎没有办法授权读取访问。我针对此问题找到的所有解决方案都建议通过处理授权的代理（或应用程序层）路由所有 CouchDB 请求。
因此，问题是：是否可以实现一个授权层来过滤对数据库的请求，以便仅向请求客户端具有读取访问权限的文档授予访问权限，并且仍然使用 CouchDB 的复制机制？简单地说，这将是某种“选择性复制”，其中仅复制某些文档，而不是整个数据库。
我也将感谢您提供有关复制工作原理的一些详细信息的指导。 CouchDB wiki 甚至“Definite Guide”一书对此都没有太具体的描述。
I'm currently evaluating possible solutions to the follwing problem:
A set of data entries must be synchonized between multiple clients, where each client may only view (or even know about the existence of) a subset of the data.
Each client "owns" some of the elements, and the decision who else can read or modify those elements may only be made by the owner. To complicate this situation even more, each element (and each element revision) must have an unique identifier that is equal for all clients.
While the latter sounds like a perfect task for CouchDB (and a document based data model would fit my needs perfectly), I'm not sure if the authentication/authorization subsystem of CouchDB can handle these requirements: While it should be possible to restict write access using validation functions, there doesn't seem to be a way to authorize read access. All solutions I've found for this problem propose to route all CouchDB requests through a proxy (or an application layer) that handles authorization.
So, the question is: Is it possible to implement an authorization layer that filters requests to the database so that access is granted only to documents that the requesting client has read access to and still use the replication mechanism of CouchDB? Simplified, this would be some kind of "selective replication" where only some of the documents, and not the whole database is replicated.
I would also be thankful for directions to some detailed information about how replication works. The CouchDB wiki and even the "Definite Guide" Book are not too specific about that.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
这就需要复制过滤器。您可以根据您施加的任何标准来过滤出站复制，并为目标所有者提供对其自己的副本的不受限制的访问权限。
我没有机会直接使用复制过滤器，但想法是每个文档都会有一些关于谁有权访问它的信息，然后过滤机制将只允许出站复制您有权访问的那些文档到。从目标到主服务器的复制将不受限制，从而允许主服务器保留汇总副本，并可能多播对重叠数据集的更改。
this begs for replication filters. you filter outbound replication based on whatever criteria you impose, and give the owner of the target unrestricted access to their own copy.
i haven't had the opportunity to play with replication filters directly, but the idea would be that each doc would have some information about who has access to it, and the filtering mechanism would then allow outbound replication of only those documents that you have access to. replication from the target back to the master would be unrestricted, allowing for the master to remain a rollup copy, and potentially multicast changes to overlapping sets of data.
您所追求的是复制过滤器。根据 Chris Anderson 的说法，这是一个 0.11 的功能。
请参阅原始帖子
What you are after is replication filters. According to Chris Anderson, it is a 0.11 feature.
See the orginal post
以下是有关此内容的一些文档的新链接：
http://blog.couchbase.com/what%E2%80%99s-new-apache-couchdb-011-%E2%80%94-part -三个新功能复制
Here is a new link to the some documentation about this:
http://blog.couchbase.com/what%E2%80%99s-new-apache-couchdb-011-%E2%80%94-part-three-new-features-replication
事实上，正如其他人所说，复制过滤器是实现这一目标的方法。 这是一个链接，其中包含有关使用它们的一些信息。
我要补充的一个警告是，大规模复制过滤器可能会非常慢。有关此内容以及有关 couchdb 的其他细微差别的更多信息，请参阅这篇优秀的博客文章：“每个开发人员都应该了解 couchdb 的知识”。对于大型系统，在应用程序层执行复制已被证明更快、更可靠。
Indeed, as others have said, replication filters are the way to go for this. Here is a link with some information on using them.
One caveat I would add is that at scale replication filters can be extremely slow. More information about this and other nuances about couchdb can be found in this excellent blog post: "what every developer should know about couchdb". For large scale systems performing replication in the application layer has proven faster and more reliable.