Do you see any problem in the approach of CREATING INDEX on the fly when an index will be needed (for a analytics-like query “Top 10 best-selling products”) and DROP the index afterwards? The idea is to keep the number of indexes to a minimum (to not waste precious index memory). The indexes are only needed short-term for some queries which e.g. run hourly or nightly.
The use case:
Assume a Dashboard with several graphs (e.g. a pie chart with TOP-N products, TOP-N cities etc.). Each graph could be the result of a N1QL query. The number of different graphs/queries can be very high, thus the amount of needed indexes is high too. But the indexes are not needed all the time. We can fetch and persist the query-results and then the indexes are not needed anymore e.g. until the night, when the Dashboards are created.
The amount documents is always between 100k and a few 1mio items. So N1QL queries are only fast if they hit a covering index. We thought about MapReduce-Views too, but like in this topic Top N over aggregated (MapReduced) we cannot sort by the value (_count or _sum).
It seems that this “Getting the TOP-N documents grouped by some attribute” is a pretty hard use case for CB if you are dealing with a large number of documents and a large number of different JSON-structures (which requires lots of different indexes).
Any ideas would be appreciated.
CB 5.0.0 beta2