使用 couchdb 进行每用户数据库复制
我有一个应用程序，其中包含对用户敏感的信息。据我所知，我应该使用每个用户架构的数据库。我希望每个用户的数据库（可能是客户端）复制到位于公共服务器上的数据库，并允许用户从任何设备访问应用程序，以便用户登录设备，数据库将被某些人发现公共服务器上的中间层，然后复制客户端并在设备和公共服务器之间进行同步。
看起来这就是 CouchDB 的优点（基于我的 Google 搜索），但是有没有任何示例应用程序可以实现我所描述的（或接近的）功能？我使用的是 couchdb 1.1.0。
I have an application that will contain information that is sensitive to a user. From what I can tell I should use a database per user architecture. I'd like each user's db (potentially client side) to replicate to a database located on a public server and allow users to access the application from any device such that the user would log in on the device, the database will be discovered by some middle tier on the public server and then replicated client side and synchronizing happen between the device and the public server.
It seems that's what CouchDB is good for (based on my Google searching) but are there any example apps that do what I describe (or close to it)? I'm using couchdb 1.1.0.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
是的，CouchDB 听起来非常适合这个 — 它简单的协议使其非常适合 Web 应用程序 [即使离线，请参阅 pouchdb] 和移动/桌面应用程序 [即使离线，请参阅 Couchbase 移动。
不幸的是，我不知道有什么好的公开可用的代码级示例，但基本思想是结合使用过滤复制和文档验证：
基本思想是，对于用户数据库的服务器端副本，设置验证功能，以便强制执行所需的文档模式和访问控制。最终用户获得该数据库的副本，可用于低延迟和离线访问——理论上他们可以破坏其副本，但在复制回来时，验证功能将防止服务器端数据库被损坏。
您甚至可以设置一个不可公开访问的主数据库，然后使用过滤复制将每个用户的数据同步到服务器端每个用户的数据库 - 对于集中式消息传递、聚合统计数据、仅需要备份一个数据库等很有用。
此中有一些更高级的示例href="http://blog.couchbase.com/what%E2%80%99s-new-apache-couchdb-011-%E2%80%94-part- Three-new-features-replication" rel="nofollow noreferrer">“复制的新功能” 文章，尤其是最后的“DesktopCouch”和“基于需要了解的数据共享”用例部分。
更新（2015/03/10）：我不再建议使用如上所述的 CouchDB 的过滤复制。当您尝试从中央数据库复制多个经过过滤的提要时，会出现几个性能和可伸缩性问题（如果不是还有可靠性问题）。如果需要，您可以考虑尝试 Couchbase 及其同步网关文档级读取权限，或使用
_local_seq构建您自己的每用户更改视图（受自定义中间件保护）。Yes, CouchDB sounds like a great fit for this — its simple protocol makes it a great fit for web apps [even offline, see pouchdb] and mobile/desktop apps [again even offline, see Couchbase Mobile.
Unfortunately, I don't know of a great publicly available code-level example offhand, but the basic idea is to use a combination of filtered replication and document validation:
The basic idea is that for your server-side copy of the user database you have validation functions set up so that desired document schemas and access control is enforced. The end user gets an replica of this database that can be used for low-latency and offline access — theoretically they could subvert their copy, but when replicating back the validation function will prevent the server-side database from getting corrupted.
You can even set up a master database that is not public accessible, then use filtered replication to sync each users' data to the server side per-user databases — useful for centralized messaging, aggregate stats, needing only to back up one database, etc.
There's a few more high-level examples in this "New Features in Replication" article, especially the "DesktopCouch" and "Need-to-know-based Data Sharing" use case sections towards the end.
UPDATE (2015/03/10): I no longer recommend using CouchDB's filtered replication as described above. There are several performance and scalability problems (if not also reliability concerns) that come up when you try to replicate more than a few filtered feeds off of a central database. You might look into trying Couchbase and its Sync Gateway if you need document-level read permissions, or build out your own per-user changes views (secured behind custom middleware) using
_local_seq.