couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Miller <alexmil...@apple.com.INVALID>
Subject Re: FoundationDB & Multi tenancy model
Date Tue, 19 Mar 2019 02:25:56 GMT

> On Mar 18, 2019, at 10:32 AM, Steven Le Roux <leroux.steven@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.
Mime
View raw message