> On Mar 18, 2019, at 10:25 PM, Alex Miller <alexmil...@apple.com.INVALID> > wrote: > > >> 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.
In fact indexes are next on the docket here, and the DocumentLayer code provided some nice patterns on how to add indexes to existing collections :) But I completely agree with your larger point — I feel a lot more confident defining a compact data model to specifically support each API and query language than to come up with something sufficiently flexible and extensible to switch back and forth. Also, Steven - welcome! I know there’s been some discussion of possibly using a hash-based level of indirection in the core data storage to minimize the possibility of write hotspots and keep a predictable key length, and as Bob points out we haven’t quite bottomed out into an RFC on that topic yet. My gut instinct is that this is not the right tradeoff for CouchDB, but I could be convinced otherwise. Most discussions happen here and in the #couchdb-dev channel on freenode. Would be happy to see if there’s some way we can collaborate. Cheers, Adam
