Tuning cluster for view queries as primary read access
I have a Couchbase application where reads are almost exclusively via Map/Reduce view indexes, with little direct access to documents.
There will be a relatively high number of document writes to the cluster.
Queries may return stale data.
After reviewing the docs, using stale reads at query time combined with auto updated views would seem to offer a good tradeoff.
But are there other considerations or tradeoffs that I should factor when tuning a cluster for this type of usage pattern?
To speed it up why don't you just create a new vBucket called "Cache" and store your view results in it and give a TTL of 1 second. Also just set the view to stale="update_after".
When you say "Queries may return stale data" are you:
a) talking about the fact that "Couchbase queries could return stale data"?
b) the fact that your application can deal with some stale data on some queries in your application?
To answer directly your question, as you have seen in the documentation, the document are eventually indexed and the queries are eventually consistent
Everything occurs asynchronously on the server side: for performance and resource consumption reason.
If your application is ok with stale data you can just let the system as it is with the default:
- query with a stale = "update_after"
- and the auto update of the index every 3s or 5000 operations.
This even if you have lot of writes, should allow you to have very good performance and good views of your data.
When you say that you have a "high number of document writes" could you tell us more about that? What is "high" ?
So I would start with the default and see if this fits your needs. (keep it simple) and only for some queries when it is really necessary change the stale parameter.