We have large data sets with around 25+ document types. We have used following optimization techniques: -
-
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.
-
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. -
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.
-
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.\
-
Do follow guideline given in the guide (https://developer.couchbase.com/documentation/mobile/1.4/guides/couchbase-lite/native-api/view/index.html#rules-for-the-map-function)
very strictly. It may look like I am doing this much only but it hits the performance very badly. -
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.
-
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,
Regards
Pankaj Sharma