Hi folks, sorry I missed this post earlier.
performance of views depend on a few things; the fanout (#nodes involved in view query processing), disk write performance for the view, #views/design docs, view definitions (map and reduce code complexity) and finally the staleness setting (stale-false vs ok). stale-false starts the query only after indexer has indexed all operations up to the moment of the stale-false query timestamp. this is currently the only way to guarantee RYOW (read your own write). View performance is constantly increasing and we have some enhancements in 4.0 as well. So I’d highly recommend looking at 4.0 or even better 4.1 for performance of views.
With 4.0, we also introduced N1QL and GSI (Global Secondary Indexes). in 4.0 you can use the same staleness settings to get the RYOW guarantee but One important improvement in N1QL and GSI for query latency is we are not required to fan out the query if we have the right index (GSI) for your query. Covering indexes and prepared execution can cut down on the query execution even more.
We are also adding a new option for faster RYOW queries. We are introducing a new setting in between stale-false and stale-ok that can give you a bounded consistency setting. We have not named this new setting but lets call this stale-at-timestamp. the new setting would let you grab the timestamp of your update and pass that to your query, so we don’t have to update the index to the timestamp of the request but only up to the point of the “update” you care about. We will be introducing this option in the upcoming releases for N1QL. If you are not satisfied with the performance of views and stale-false, highly recommend you look at N1QL and explore the stale-at-timestamp setting when that becomes available.
if you are interested learning more about it, feel free to reach out to me at cihan@couchbase.com
thanks
-cihan