Best property to optimise views in couch-base lite

We have large data sets with around 25+ document types. We have used following optimization techniques: -

  1. Try to design views in a way such that One view mapper is dependent only on one document. Even if you have to duplicate the data do it.

  2. Design Keys as it were the columns of SQL query. To think about the sequence. You can concatenate them according to the priority of search. For example in SQL if you write a query as follows :
    Select ID from TableEvent Where EventDate =@date and EventStatus= @EventStatus
    Order by SortingColumn then The Key I will design is as follows :
    < EventDate >_ _ _ID
    Now you can use start keys and end keys with prefix match level =1 and get the result for all range you want. There may be a better way but this works for me. I would like to know other better ways too. Arrays do provide duplicate results so I haven’t used them but if somebody can suggest a better way please do.

  3. Be aware if a similar key is emitted from 2 different documents then the database will have 2 entries in the view. Which can mislead counts. Yes you can use group level but. What if in update only one document is updated and other is not. Then you will have one updated key and one old. which with group level increase count as one place and will not decrease count at other.

  4. If the mapper of a view only gonna traverse one type of document then use setDocumentType() property of view. and then no need of checking type inside the mapper. This will make sure that only specified document type enters the mapper. So lets say you have a document type with 5000 total document but over all the database is having 200000 docs , then using this property will make sure the mapper code is only executed 5000 times. without it and with if condition it will scan all 200000 documents, even if they kicked out by the if condition. It will make live queries faster and lighter.\

  5. Do follow guideline given in the guide (
    very strictly. It may look like I am doing this much only but it hits the performance very badly.

  6. Live query doesn’t help much when you want to know which record is changed. In this case Database change listener is your friend. Do see To Do Training app code in couchbaselabs git repository to understand how to use it.

  7. Try to design keys in such a way that only one view per document type is required. Get the right balance between normalisation, de-nomalisation and network usage.

I will keep you updated if I find more things,

Pankaj Sharma

1 Like

Arrays are the usual way to do what you’re describing (primary / secondary keys.) String concatenation as you’re using will work too, but you have to be careful about what you use as the delimiter to avoid ambiguities. I’m not sure what you mean about “duplicate results”?

Arrays are one of the best things to do. But as Array keys can be duplicate is it possible that I have emited [a,b,c] from doc1 and next time when doc 1 changes it emmits [a,b,d], will both key be present in the view or the later will replace first one.