Thanks Jan, On Sun, Jan 27, 2019, 3:43 AM Jan Lehnardt <m...@jan.io wrote:
> The FDB proposal is starting at a higher level than the pluggable storage > engines. This isn't just about storage, but also about having a new > abstraction over the distributed systems aspects of CouchDB. > Right, FoundationDB would *also* replace all of the internal-cluster-replication, since it is already a scalable distributed database. I was just curious if we'd be able to leverage the pluggable storage engine work. I.e. could the other parts that change (fabric, etc) *also* be swapped out such that foundationdb or legacy couch_bt_engine+fabric could be selected on a per db basis. Maybe not, but IMO it'd still be interesting if we could somehow try out a foundationdb pluggable storage engine as a proof of concept. As for reduce: CouchDB will *not* lose reduce. Details are TBD, so let's > wait to discuss them for when the technical proposal for that part is out, > please. > > So far, all IBM has mentioned is that in their preliminary exploration of > this, they couldn't find a trivial way to support *efficient querying* for > *custom reduce functions* (anything that isn't _sum/_count/_stats). > Yes, I understand all of that. But I *really* *really* need efficient querying for custom reduce functions. Ideally, I'd like group_level queries to be even *more* efficient than they currently are. I wasn't trying to jump into a deep technical proposal. I was just putting forward a naive napkin sketch level idea, and wondering if it could possibly work as a trivial way to support efficient queries on custom reduce functions. I either need that to stay (or improve) or else I need some new features (i.e. view changes feed, dbcopy, etc) that make it easier and worthwhile to rewrite all of my code that relies on it. Because if I had to had to significantly change my codebase to migrate to CouchDB 4.0, I honestly think my bosses might opt to replace our storage layer with something other than CouchDB rather than upgrade. Thanks, Nick Evans >
