Views and their memcached behaviour
Hi, love what you're doing here with Couchbase 2.0. Really interesting and FAST.
I've evaluated couchDB before I found this project, and I think this fits our needs better, but I have some questions regarding how views work in couchbase.
1. According to the webinars once the production views are generated they will reside in RAM and get updated only when you query them (either on stale=false or stale/update after). But you can choose whether to use reduce in the call. Are both reduced and unreduced data cached in RAM? Are they both generated when you create your view and choose to run in on the whole data set?
2. Same for grouping - you can choose grouping level on query. Are all grouping levels cached in RAM? Considering memcached's background I'd assume they are once they've been queried. Are the view cache dropped using the same rules as regular key/value in RAM or are they dropped sooner/later? (If RAM gets full)
3. In the webinar you mentioned that before publishing a development view into a production view you should run it on the whole dataset so it's already generated and available when you publish the view.
If you run a dev view on the whole data set, how long do you store the view data? Could it be dropped because of high load on the server BEFORE I had time to publish the view as a production view?
thanks in advance and keep up the good work!
Thank you for the answer!
I really haven't tested with any Real Big Views yet, the tests I've done so far were fast enough to fool me they were in RAM :P
Regarding my 3:rd question, what I really was after was how we can minimize the user slowdown when publishing a view to production.
The proposed workflow is to
1. Edit development view
2. Run the view on the whole set
3. Publish the view
That way the whole view data is already generated when you publish, and the users shouldn't notice a thing.
So this data is never removed? Even if I leave the view in developer mode?
Correct. You can continue accessing a view (keeping it up to day) while it is in development. Theoretically you could run your whole application off of development views, but the advantage to publishing is that you get the ability to edit a view in the "background" without affecting your existing production deployments.
Changing a view (whether on purpose or by accident) would end up flushing all the results and so you don't really want to do that on a view deployed in production.
Make sense?
Perry
Hi there Joakim, glad you like what we're doing! :-)
For your first two questions, the view data is not actually stored in RAM (that's an enhancement for a future version). So the stale and grouping options only apply to the data coming out of the database and don't interract with memcached (yet).
For your third question, a dev view is treated just like any other view in that it will be kept around for as long as you decide. As opposed to the concept of temporary views (related only to Couchbase Single Server and CouchDB) which get cleaned up.
Hope that answers things, let me know if you have any followups.
Perry
Forum support is great for free but sometimes you need a guaranteed response time and dedicated resources for your questions or issues.
Consider purchasing enterprise-level support from Couchbase: http://www.couchbase.com/products-and-services/overview
Call or email "sales -at- couchbase-dot- com" today!