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.
Simple Replication with the Admin InterfaceStart CouchDB and open your browser to http://127.0.0.1:5984/_utils/ . On the righthand side, you will see a list of things to visit in Futon. Click on “Replication.” Futon will show you an interface to start replication.
Replication Procedure. During replication, CouchDB will compare the source and the destination database to determine which documents differ between the source and the destination database. It does so by following the Changes Feeds on the source and comparing the documents to the destination.
Faster reads: MongoDB provides faster reads than CouchDB as MongoDB uses a binary protocol that is faster than CouchDB's RESTful HTTP API method. Replication: MongoDB only offers master-slave replication across replication sets.
CouchDB is safer than MongoDB. MongoDB, the database contains collections and collection contains documents. CouchDB is eventually consistent. MongoDB is strongly consistent.
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
.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With