When use Couchbase Views instead of N1QL?

Hi everyone! My question is, when is it recommended to use couchbase views and when N1QL for querying? Are these systems very different in terms of performance?

@donadev, great question!
Let me take a stab on a few major differences in SQL for Documents (N1QL) - I’ll assume you know views so I’ll focus on N1QL:
- Ad-hoc queries: change your query without having to build a dedicated “View” under it.
- Expressive language: powerful aggregations, grouping, projection, subqueries and unique verbs like JOIN, NEST UNNEST - see N1QL language reference.
- New Consistency Dials: N1QL is coming with additional consistency dials beyond stale=ok, update_after and false. It will give you much better control over the consistency with ScanConsistency (see SDKs).
- Seamless Integration with tools ecosystem: ODBC/JDBC - N1QL will let you reuse your queries across multiple tools and your app. You can use your N1QL in Tableau or Excel.
- New deployment topologies (MDS): N1QL has ability to deploy query service in a separate isolated zone for dedicated computational capacity and better isolation. (look for multi-dimensional scaling here)
- Indexing: This one is huge so I’ll double-click this one
N1QL has the Ability to take advantage of both views and secondary indexes (GSI) as the indexer. (With views, obviously you can only use view indexer). Here are the differences between views and global secondary indexes (GSI):

and with these I am just scratching the surface but hope this gives you some overview of the differences.

Hi @donadev,

In addition to what @cihangirb said, I would summarize the recommendation as follows.

Beginning with Couchbase 4.0, N1QL will be the most general way to query Couchbase (i.e. non-KV access). Views will continue to be recommended for the following cases:

  1. Using Javascript logic as part of the query
  2. Performing aggregation (reduce), materializing the results, and then maintaing the results incrementally as the source data is modified.

(2) is important for performance, because the aggregate results are essentially pre-computed.

Hi Geraldss,
Can you elaborate on point 2?

Aren’t reduce functions calculated every time? I was of the impression that only the index produced with map was precomputed.

Or I did misunderstand? I can’t follow what you mean by materializing the results.

Reduce functions are not calculated every time you query the view.

I don’t understand how it’s possible given that it’s based on the queried keys.
How can for example a simple count reduce be precalculated if I can select a different key range every time and the result will be always different?
At most it can be cached.

Yes, you can think of it a cache. This is the same as a materialized view in RDBMS, which is also a cache.