On Thu, Jul 23, 2020 at 6:55 PM Paul Davis <paul.joseph.da...@gmail.com> wrote:
> > I would like to keep ebtree to use just for the reduce index. > > Could you expand on your reasoning here, Garren? I haven't done any > experiments on my own to understand if I'm missing something > important. My initial reaction is to not diverge too far from the > previous shape of the implementation since we have a decent idea of > how that behaves already but perhaps you've seen or measured something > I'm not thinking of? > I think this must have been a misunderstanding on my part. I always thought of using ebtree to solve reduce and wasn't planning to use it for the map index. I don't like the idea that we have ordered distributed key/value store and then implementing a b-tree on top of that for indexing. Especially since we know that the current map index is fast, easy to use, and follows recommended practices in the FDB community on how to do indexing. ebtree makes sense for reduce and is a means to an end to give us CouchDB's reduce api, which is heavily reliant on a b-tree, with CouchDB on FDB. This feels like a step backward and I worry we are tying ourselves heavily to old CouchDB instead of using the fact that we moving to FDB which then allows us to design new api's and functionality.
