couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eli Stevens (Gmail)" <>
Subject Re: [DISCUSS] Rebase CouchDB on top of FoundationDB
Date Fri, 01 Feb 2019 17:21:35 GMT
A couple other topics that I think would make sense to discuss:

- How to manage edge-case performance or capability regressions resulting
from the switch. My former team couldn't use 2.x in production until
2.2 due to a handful of these kinds of issues. What's going to happen when
users blocked due to things that can only be addressed on the FoundationDB
side of things? Will CouchDB have a privileged seat at the table when it
comes to requesting bugfixes or performance improvements from the
FoundationDB team?
- What's going to happen to attachments?  I'd really like them to get out
of the "supported, but conventional wisdom is don't use them" limbo they're
in now (either by becoming a first-class feature, or by officially
deprecating them).


On Thu, Jan 31, 2019 at 9:40 AM Adam Kocoloski <> wrote:

> > On Jan 31, 2019, at 12:27 PM, nicholas a. evans <
>> wrote:
> >
> >> I called out the problems with reduce functionality in the first post
> of this thread specifically to shake out people's concerns there, so thank
> you for voicing yours. The current approach to reduce only works because we
> control the writing of the b+tree nodes, including when they're split, etc,
> so we're able to maintain intermediate values on the inner nodes as the
> data changes over time. This is not something we can do with FoundationDB
> directly (or, indeed, anything else). We're looking for a solution here.
> >
> > Yes, I don't want to dive too deep into the nitty gritty here (my
> > experience with FoundationDB is only a quick skim of the docs,
> > anyway). I was thinking of something along the lines of making a
> > pseudo-btree (just for reductions, distinct from the map emits) where
> > each btree node is a FoundationDB value. It might not be useful or
> > efficient for anything *other* than ranged reduce queries, so perhaps
> > it could be opt-in per ddoc or per view (and v4.x, where x > 0). It
> > could be updated within the same transactions as the map emits, or
> > maybe it could be updated as a cache layer separately from the map
> > emits.
> That’s at least the third time I’ve heard someone independently come up
> with this idea :) I think it could work, if anyone has the cycles to sit
> down and write that code.
> Adam

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message