Hello,
I understand that view query is not real time unless I set ‘stable’ option value.
What about N1QL queries? Does it behave just like view? Or does it perform full scan?
What is the default behavior of N1QL in this regard?
With 4.0 and 4.1 that is coming shortly, N1QL exposes 2 settings: scan_consistency:unbounded or request_plus these are identical to stale-ok and stale-false respectively. N1QL default is scan_consistency:unbounded (stale-ok)
thanks
-cihan
Thank you @cihangirb
It’s off topic, but is there a benchmark where it shows how we determine whether I should depend on “stale - ok” or not? I just can’t find a benchmark for the view performance when it is very important part of the Couchbase.
We have some numbers we use to compare release to release, but those probably won’t be that useful to you since the latency of update will primarily be influenced by the complexity of your views (if talking views) and the underlying system capabilities.
I’m sorry for the non-answer answer, but we know request_plus for N1QL and stale=false for views can be in the 10s of milliseconds, if the underlying deployment supports that throughput.
The stale-false results depend on a number of factors like mutation rate of data (how fast you can index under such mutation rate) and complexity of views in the case of a View Query and in the case of N1QL. So it is hard to share a single number. In a system with no mutations, there isn’t much of a difference between them.
If you don’t need the guarantee from stale-false, it is always better to use stale-ok. However with N1QL, we are also introducing a new staleness guarantee in future. Some of this was discussed here at slide #31
http://connect15.couchbase.com/agenda/introducing-global-secondary-indexes-new-high-performance-indexing-couchbase-server-4-0/ . I am wondering if you’d find this interesting for your case?
thanks
-cihan
Thank you @ingenthr
My views are really basic. If it is under 1 sec, that is good enough for me. Thank you 
Thank you for the link! That helps a lot 