Omni caches data at several layers to improve performance and reduce load on the underlying data warehouse. Additional configuration will be built in the future to fine tune cache controls.
Omni caches the results of individual queries to share between users observing the exact same data sets. Query results are cached for 6 hours, and shared between users with relevant permissions to the data set.
This means if one user queries a workbook or dashboard and shares the link with another user, the second user's results will frequently come from the query cache. This cache will only trigger for exact match of the query (all fields, pivots, filters, sorts).
The query cache can be cleared on an ad hoc basis:
- From the workbook: Tab > Run w/o Cache
- From the dashboard: View > Refresh Data
In addition to the exact match cache, Omni will cache data for requery, offering acceleration to similar follow up queries, filtering, or sorting during a given session.
This cache is volume based and will hold the last 30 query results from a session. When data is returned without hitting the query limit, Omni will requery the data set when appropriate, offering much quicker query response times (as the data is queried in the browser).
Example of the requeryable cache:
- Resorting a data set:
- Orders last 30 days, by day, sorted by day descending --> invert to sort ascending
- Filtering a result set:
- Orders last 30 days, by day --> Orders last 7 days, by day
- Regrouping a data set:
- Orders by city (note query limit must not be hit) --> Order by state
- Orders by date, status --> Orders by date, pivoted by status
Here's a quick example where we aggregate users over a random selection of states in memory. We also quickly show the comparison to dropping back down to the database:
Taking Advantage of the Requeryable Cache
Huge unlocks in performance are available when being thoughtful about caching. Whole dashboards can be brought in memory for instant slice and dice, rather than each filter permutation hitting the database. Over time this will be automated for dashboards, but to build requeryable dashboard caching, the filters can be appended to dashboard tiles to build cubes.
A simple example:
- This dashboard has one single-value tile counting total orders in the filtered set
- The table on the right shows the requeryable data set needed to cache each filter permuation
- The underlying value:
- The filters:
- The underlying value:
This means when the table to the right is loaded, we have every permutation of the filters, and all requery will be in-memory in the browser. This technique can be refined for entire dashboards to create psuedo-instant query response times.
Currently the exact-match cache has a 6 hour expiry window. The browser requeryable cache will stay as long as the window is active, so may persist longer than expected. These will become configurable in the future.