Druid currently supports per segments cache for historicals and brokers (often not recommended as it results in historical not being able to perform merges). Even with cache enabled, broker still needs to do all merging.
We have many users that deploy custom caches outside of Druid to cache end query response from brokers in systems like memcache and redis etc. It has been proven beneficial in many different use cases. However, it has been something that requires work for each cluster operator.
So, this proposal is to build a result level cache in Druid using probably the existing Cache interface so that user could opt to store existing cache implementations to store cached data. Implementation would also use the "etag" facility already available in QueryResource to quickly see if query response can be returned immediately from cache or it should be computed.
Considering query results could be very large also, so there would be an upper limit on the size of response that could be cached.
Druid currently supports per segments cache for historicals and brokers (often not recommended as it results in historical not being able to perform merges). Even with cache enabled, broker still needs to do all merging.
We have many users that deploy custom caches outside of Druid to cache end query response from brokers in systems like memcache and redis etc. It has been proven beneficial in many different use cases. However, it has been something that requires work for each cluster operator.
So, this proposal is to build a result level cache in Druid using probably the existing Cache interface so that user could opt to store existing cache implementations to store cached data. Implementation would also use the "etag" facility already available in QueryResource to quickly see if query response can be returned immediately from cache or it should be computed.
Considering query results could be very large also, so there would be an upper limit on the size of response that could be cached.