Hello, Just to add the modest perspective of a user. I appreciate the benefits of taking advantage of the infrastructure provided by FDB both from a quality perspective and from a maintenance and ease of expansion perspective.
However, this development makes me really worried of being burned as a user so to speak. Losing arbitrary reduce functions would be a big concern. But losing arbitrary startkey and endkey would be an even bigger concern. This is not about the inconvenience of updating our codebase, this is about losing the ability to do quite significant things, losing expressiveness so to speak. We make extensive use of startkeys/endkeys for things ranging from geoqueries using a simple application-based geohash implementation, all the way to matching the documents belonging to a tenant using complex keys. So if this is indeed the feature we'd be losing, this is quite a big deal in my opinion. I think all our data access layers would need to be rewritten but I do not even know how. For I do not know if we are representative, but we intentionally stay away from Mango to leverage the performance benefits of using precomputed views which see as a key feature of Couchdb. Mango is quite non-deterministic when it comes to performance (defining the right indexes is cumbersome compared to using views, and its difficult to know if a query will be completed by doing in-memory filtering). And people keep reporting a number of troubling bugs. So moving people to Mango is not only about updating applications, this is also losing quite substantial features. All in all, my point is that with that the changes I hear, I feel like a lot of the technical assumptions we made when we settled on Couchdb would no longer hold. There are patterns we wouldn't be able to use, and I don't even think that it would still be possible to develop real world applications solely relying of the view/reduce pipeline only if we do not have the level of expressiveness provided by custom reduce and arbitrary startkeys/endkeys. Without these two structures, we will burned in certain situations. Just wanted to voice this concern to highlight that there are folks like us for who the API of the view/reduce pipeline is central. So that hopefully this can be taken into account as the merits of this proposal are being reviewed. ________________________________ De : Dave Cottlehuber <d...@skunkwerks.at> Envoyé : samedi 26 janvier 2019 15:31:24 À : dev@couchdb.apache.org Objet : Re: [DISCUSS] Rebase CouchDB on top of FoundationDB On Fri, 25 Jan 2019, at 09:58, Robert Samuel Newson wrote: > Thanks for sharing this Bob, and also thanks everybody who shared their thoughts too. I'm super excited, partly because we get to keep all our Couchy goodness, and also that FDB brings some really interesting operational capabilities to the table that normally you spend a decade trying to build from scratch. The level of testing that has gone into FDB is astounding[1]. Things like seamless data migration, expanding storage and rebalancing shards and nodes, as anybody who's dealt with large or long-lived couchdb clusters knows are Hard Problems today. There's clearly a lot of work to be done -- it's early days -- and it changes a lot of non-visible things like packaging, dependencies, cross-platform support, and a markedly different operations model -- but I'm most excited about the opportunities here at the storage layer for us. Regarding handling larger k/v items than what fdb can handle, is covered in the forums already[2] and is similar to how we'd query multiple docs from a couchdb view today using an array-based complex/compound key: [0, ..] would give you all the docs in that view under key 0 except that in FDB that query would happen for a single couchdb doc, and returning a range query to achieve that. Similar to multiple docs, there are some traps around managing that in an atomic fashion at the higher layer. I'm sure there are many more things like this we'll need to wrap our heads around! Especial thanks to the dual-hat-wearing IBM folk who have engaged with the community so early in the process -- basically at the napkin stage[3]. [1]: https://www.youtube.com/watch?v=4fFDFbi3toc [2]: https://forums.foundationdb.org/t/intent-roadmap-to-handle-larger-value-sizes/126 [3]: https://www.computerhistory.org/atchm/the-two-napkin-protocol/ the famous napkin where BGP, the modern internet's backbone routing protocol, was described. A+ Dave
