On Mar 11, 2014, at 11:57 AM, Traun Leyden <
traun....@gmail.com> wrote:
> Btw there are known scaling issues with this approach. @Jens do you have a link to a description which gives details?
I don’t know of any canonical written description of the problem (but @JChris might?) but the basics are:
* Filter functions are not super fast (written in JavaScript)
* The filter function has to be called once on every revision added to the database, for every user replicating with the database. So if you have 100,000 users, every new doc that gets added to the database will incur 100,000 executions of the filter function.
It’s probably not an issue for small sites, but doesn’t scale to big ones.
The alternative approach with CouchDB is to set up a database for every user, containing only the docs relevant to that user. The biggest problem with that is if documents are to be shared between users; then you have to set up a network of replications between the databases. Probably the cheapest way is to have a central db that has everything, and a pair of filtered replications between it and every user’s database. This has some pretty serious scaling limits too. Not only does a new update from a user wake up 99,999 pull replications once it arrives at the master database, but all of those replications are filtered so you have the same scaling issue as above.
This is pretty much exactly why we designed the Sync Gateway the way we did, with channels.
—Jens