incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <rnew...@apache.org>
Subject Re: Post-mortem
Date Fri, 11 May 2012 12:29:39 GMT
I'll pick up a few points here: "I don't know if it is possible to
restructure the code to serve up other views from the same design
document while one is being rebuilt."

It's possible but it's not happening. It's deliberately the case that
all views in a design document are built together, they are written to
the same file (which is why they all get rebuilt if you change one,
and why they're all unavailable while that happens). There's a
performance boost to grouping them together and some deduplication of
identical rows emitted from different views too.

Where I believe we've failed (or, if you prefer, not yet succeeded) is
communicating this information to the public. Additionally, the system
we've built to allow views to be built in production without
interfering with existing queries (the main trick being that the view
file is named for the MD5 of the source code) is not widely known. I
see many people complaining about these issues that we have always had
a solution for.

Making a single view indexing process faster keeps coming up. For one
thing, it's not that easy, otherwise it would have been done by now.
For another, this problem vanishes when you shard (and the BigCouch
merge will bring this to CouchDB). For another, this problem vanishes
when you have many databases and many views. It feels a lot like the
delayed_commits argument. It's true by default because if you do a
very poor benchmark (serial insertions) you get bad numbers, because
we fsync so often. It's unrealistic, even demeaning, for a database
test. Likewise, building a single view, from scratch, for millions of
documents. Yes, that's slow. No, it's not very realistic. Yes, the
equivalent CREATE INDEX would take a while too.

Finally, if your couchdb problem can find a sane MySQL solution, I'd
argue that couchdb wasn't the right solution in the first place.
That's not our fault.

B.

On 11 May 2012 08:31, Jason Smith <jhs@apache.org> wrote:
> On Fri, May 11, 2012 at 12:56 PM, Benoit Chesneau <bchesneau@gmail.com> wrote:
>> On Thu, May 10, 2012 at 7:53 PM, Noah Slater <nslater@tumbolia.org> wrote:
>>> Guys,
>>>
>>> What can we learn from this:
>>>
>>> http://saucelabs.com/blog/index.php/2012/05/goodbye-couchdb/
>>>
>>>
>>> Thanks,
>>>
>>> N
>>
>> Note apart: I'm not even sure they did the right choice in choosing mysqL.
>
> Well they *do* have a history of smart, prudent decision-making. So I
> put faith in them. (Personally I am dying for a reason to get into
> Drizzle, but CouchDB solves my current problems.)
>
>> For the rest we should market couchdb on what it really does.
>
> Enthusiastic +1
>
>> Some
>> are dreaming about big data, big central cluster blahblah. But not
>> everyone need that. Most companies have usable data < 2GB.
>
> I wouldn't call it "blah blah" but rather that CouchDB needs a gentle
> on-ramp. (Is that an Americanism?) A slip road. Some obvious killer
> app to go from zero to sixty (if I may press the metaphor).

Mime
View raw message