Hi All We have a new reduce design for FoundationDB and we think this one will work. Recently I proposed a simpler reduce design [1] and at the same time, Bob (rnewson) looked at implementing a B+tree [2], called ebtree, on top of FoundationDB. The b+tree implementation has turned out really nicely, the code is quite readable and works really well. I would like to propose that instead of using the simpler reduce design I mentioned in the previous email, we rather go with a reduce implementation on top of ebtree. The big advantage of ebtree is that it allows us to keep the behaviour of CouchDB 3.x.
We have run some basic performance tests on the Cloudant performance clusters and so far the performance is looking quite good and performs very similar to my simpler reduce work. There is an unknown around the ebtree Order value. The Order is the number of key/values stored for a node. We need to determine the optimal order value for ebtree so that it doesn't exceed FoundationDB's key/value limits and still performs well. This is something we will be looking at as we finish up the reduce work. The work in progress for the reduce PR is https://github.com/apache/couchdb/pull/3018. A great thanks to Bob for implementing the B+tree. I would love to hear your thoughts or questions around this? Cheers Garren [1] https://lists.apache.org/thread.html/r1d77cf9bb9c86eddec57ca6ea2aad90f396ee5f0dfe43450f730b1cf%40%3Cdev.couchdb.apache.org%3E [2] https://github.com/apache/couchdb/pull/3017 [3] https://github.com/apache/couchdb/pull/3018
