> On Mar 18, 2019, at 10:32 AM, Steven Le Roux <leroux.ste...@gmail.com> wrote: > > Also, did anyone considered reaching > the FDB guys to try to align CouchDB document representation to the > Document Layer ( > https://foundationdb.github.io/fdb-document-layer/data-modeling.html ). > This would make CouchDB to be also MongoDB API compatible.
In reading through the proposals, I’ve been left with the impression that although the FDB document layer and proposed CouchDB layer would potentially overlap in how to persist a JSON object to FDB, the higher level goals are sufficiently different to make this level of sharing seem difficult to achieve. The document layer would know nothing of revisions or change feeds, and the CouchDB layer would know nothing of indexes or extensions like GridFS. Overall, I’ve seen a lot of excitement in being able to have data that’s useable via multiple different APIs, and I agree it would be cool, but from the implementation side I haven’t yet managed to sketch out how to make it work in a modular, extendable way. > I'm curious on how you're considering to manage multi tenancy while > ensuring a good scalability and avoiding hotspotting. I’ll issue a similar note of caution that FoundationDB isn’t a natively multi-tenant database either. The transaction rate limiting done in FoundationDB applies globally, so a small set of clients focusing a read hotspot on a single key, or trying to bulk load data in faster than FoundationDB can keep up will impact the latencies seen by other clients connected to the same database.
