Tuning cluster for view queries as primary read access

Couchbase Server
1

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?

2

Hello,

When you say “Queries may return stale data” are you:
a) talking about the fact that “Couchbase queries could return stale data”?
or
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.

Regards
Tug
@tgrall

3

Tug

Hi, thanks for the response.

With regards to stale data, the App can cope with potentially stale data in the results, so has no issue if couchbase queries return stale data.

If the defaults should give good performance for this type of use case then I’ll keep it simple as you suggest and monitor performance once under load.

My statement about the number of writes was more about my expectation of the usage profile, I am not in production yet so do not have hard figures for document writes which will depend on service take-up.

I am now confident that I can move forward with this model and I am not building any issues into the design.

Thanks

Andy

4

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”.