Changing a CouchDB view

[Luke Sneeringer <lu...@gmail.com>]

Good morning, CouchDB peoples! :-)

In a few days, I am going to embark on a bit of CouchDB system adminstritivia, and I would appreciate it if a couple folks would be willing to read over my evil plans and tell me if I'm making any mistakes. But, pay no attention to the large red button conspicuously labelled "SELF-DESTRUCT", of course.

On to business:
I have a CouchDB database. Everyone say, "Hi, database!". It's decently large (about 1 GB of textual data across maybe 120,000-ish updates). I also have a design document with two views that I use in order to pull back these documents based on their contents. Anyway, if this view were ever to substantively change, CouchDB must rebuild the view, which is a lengthy process (20 minutes or so?), and the view can't be queried until it's done.

My goal is to change this view and minimize downtime.

So, here's how I plan to do it:
1. Replicate the original database to a copy on the same machine: "Hi, copy!" Give the copy the new and improved views, and let them build. This way, the original keeps going with the original views while the copy is building. Of course, the original view is receiving new updates. This means the bulk of the view rebuild time is happening now, and my project is still in a working date.

2. Put site in maintenance mode, stop CouchDB.

3. Rename the databases (flip flop them).

4. Bring CouchDB up.

5. Replicate the old, outgoing database to the new one again -- this would get the new updates that came in during the view rebuild process, and the new views would only have to build that small delta (almost instantaneous).

6. Bring site out of maintenance mode.

So, my question:
- Is this process a good one? Is there a better one I am not seeing?
- Any pitfalls or snags I should know about?

Thanks!
Luke Sneeringer

Re: Changing a CouchDB view

[Adam Kocoloski <ko...@apache.org>]

On Jan 12, 2010, at 12:00 PM, Luke Sneeringer wrote:

> Good morning, CouchDB peoples! :-)
> 
> In a few days, I am going to embark on a bit of CouchDB system adminstritivia, and I would appreciate it if a couple folks would be willing to read over my evil plans and tell me if I'm making any mistakes. But, pay no attention to the large red button conspicuously labelled "SELF-DESTRUCT", of course.
> 
> On to business:
> I have a CouchDB database. Everyone say, "Hi, database!". It's decently large (about 1 GB of textual data across maybe 120,000-ish updates). I also have a design document with two views that I use in order to pull back these documents based on their contents. Anyway, if this view were ever to substantively change, CouchDB must rebuild the view, which is a lengthy process (20 minutes or so?), and the view can't be queried until it's done.
> 
> My goal is to change this view and minimize downtime.
> 
> So, here's how I plan to do it:
> 1. Replicate the original database to a copy on the same machine: "Hi, copy!" Give the copy the new and improved views, and let them build. This way, the original keeps going with the original views while the copy is building. Of course, the original view is receiving new updates. This means the bulk of the view rebuild time is happening now, and my project is still in a working date.
> 
> 2. Put site in maintenance mode, stop CouchDB.
> 
> 3. Rename the databases (flip flop them).
> 
> 4. Bring CouchDB up.
> 
> 5. Replicate the old, outgoing database to the new one again -- this would get the new updates that came in during the view rebuild process, and the new views would only have to build that small delta (almost instantaneous).
> 
> 6. Bring site out of maintenance mode.
> 
> So, my question:
> - Is this process a good one? Is there a better one I am not seeing?
> - Any pitfalls or snags I should know about?
> 
> Thanks!
> Luke Sneeringer

Hi Luke, there's an easier way.  View indices are stored according to the hash of the functions in them, so you could add a "staging" design doc with the new version of your views, trigger a build, and then copy the contents of that design doc to the production design doc.  Your production app should switch over to the newly built indices with zero downtime.  In fact if you like you can use HTTP COPY from staging to production to ensure there are no typos when you deploy :)  Best,

Adam