问题
I have an application with the following architecture:
The master couchdb is required to share data between the users. EG: If user-1 writes data to the cloud, this replicates to the master and back to user-2 and user-3.
However, as the user base increases so do the number of cloud user couchDBs, which results in a large number of replication links between the cloud user couchDBs and the master couchDB.
I believe this can lead to a huge bottleneck. Is there a better way to approach this problem?
回答1:
You’re right: the db-per-user pattern for CouchDB can run into scalability issues. This is to do with the fact that the CouchDB replicator will struggle to service the number of simultaneous replication jobs it is asked to handle. If you know that your user numbers will grow over time it’s worth considering architectures that multiplex many users’ data into a single (or a handful) database.
This makes authentication and replication trickier, as CouchDB authenticates per database only, and you may end up with another layer in between to resolve this.
One approach is to use a replication proxy such as Cloudant Envoy, which lets your PouchDB applications remain unchanged — the model on the client side is still “db-per-user”, but the actual writes go to a single DB server side. This also means that you may be able to avoid the server side replication into a single master DB as you already have that in the main Envoy DB.
Disclaimer: I’m one of the authors of Envoy.
来源：https://stackoverflow.com/questions/48886402/couchdb-db-per-user-with-shared-data-scalability