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
