couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin R. Coombes" <kevin.r.coom...@gmail.com>
Subject Re: Post-mortem
Date Thu, 10 May 2012 19:11:16 GMT
This is obviously my off-the-cuff immediate reaction.  My first 
observation is that is tremendously useful to have this kind of detailed 
real-world feedback on what is not working.  Now we just need to decide 
what to do with it.

In the posted list of availability issues, even though there are five 
bullets, there are only really two issues.  (I'm not counting the bugs 
listed as the fifth bullet. They're fixed.  Other bugs will crop up.  As 
Couch matures, one expects this issue to decrease in importance.)  In 
summary:

Issue 1:
Compaction fails silently.  I've noticed this myself, and that is 
clearly something that has to be fixed.  Failures will happen 
sometimes.  They shouldn't be silent.  Especially when that kind of 
silent failure can eat a tremendous amount of disc space.

Issue 2:
Queries fail because of slow disk performance or while reindexing.  
Reindexing can fail, or can take an extraordinarily long time.  While 
one view is being reindexed, all views *from that design document* 
fail.  (The performance problem listed in the post, I think, comes down 
to the same thing. And so do most of the maintenance problems)

My experience with this issue is also similar, but I've added the phrase 
about design documents.  I have a couple of databases (one with 3.5M 
documents) with multiple views defined in the same design document.  I 
made the mistake of trying to develop an application on this database.  
It was really painful every time I decided that one view needed to be 
changed, and having to wait a couple of hours while all the views got 
rebuilt.  (For that purpose, I made a filtered version of the database 
with about 10K documents to use during view development.)  Although I 
haven't tested it, I'm planning to move to a structure that puts one 
view per design document to see if the other views remain usable while 
one of them rebuilds.  Since other databases remain usable, I expect 
that this will work.  It would be good to have advice somewhere on the 
Couch web site or wiki about how to organize views into documents, with 
more details about how that might affect performance.

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.  And 
while I know about "stale=ok" or "stale=update_after", both of those are 
hard to use from web sites that access the database. since they require 
modifying the URL.  And the "update_after" version only helps the first 
user, and just pushes the burden of waiting onto the next user.  If you 
have an active site with lots of users making queries, there is still 
going to be a performance hit.

Perhaps the solution is to make it possible to configure the server (on 
a per-database level? or globally?) to *always* return stale views while 
a view is rebuilding, and just mark them as stale.  Perhaps another 
reserved word, either returning something like
     _stale : true | false
or
     _currency: "stale" | "current"
so the user or script could decide whether to use that data or wait 
until the view is rebuilt (which begins suggesting other changes so you 
can query if the view is done rebuilding, but I won't follow that 
tangent any furether at the moment).

I think the bottom line is that some serious attention needs to be paid 
to real-world performance issues, primarily centered around rebuilding 
views and compaction.

     -- Kevin

On 5/10/2012 12:53 PM, Noah Slater wrote:
> Guys,
>
> What can we learn from this:
>
> http://saucelabs.com/blog/index.php/2012/05/goodbye-couchdb/
>
>
> Thanks,
>
> N
>

Mime
View raw message