[jira] [Commented] (KYLIN-2899) Enable segment level query cache

["Ma Gang (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/KYLIN-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16416822#comment-16416822 ] 

Ma Gang commented on KYLIN-2899:
--------------------------------

Add some draft design and performance test here
h2. Motivation


Currently Kylin use sql as the cache key, when sql comes, if result exists in the cache, it will directly returned the cached result and don't need to query hbase, when there is new segment build or existing segment refresh, all related cache result need to be evicted. For some frequently build cube such as streaming cube, the cache miss will increase dramatically, that may decrease the query performance.

Since for Kylin cube most historical segments are immutable, the same query against historical segments should be always same, don't need to be evicted for new segment building. So we decide to implement the segment level cache, it is a complement of the existing front-end cache, the idea is similar as the level1/level2 cache in operating system.
h2. Design
h3. 
How to enable


By default, the segment-level closed, and open only all following conditions satisfied:
1. "kylin.query.segment-cache-enabled" config is set to true, it can be set at cube level. 
2. there is memcached configured in Kylin, because segment query result can be very large, may consume lots of memory if no external cache enabled.
h3. What is cached


cache key is \{cubeName} + "_" + \{segmentUUID} + "_" + \{serlized GTScanRequest string}
cache value is SegmentQueryResult:

 
{code:java}
// result byte array for all regions of the the segment
private Collection<byte[]> regionResults;

// store segment query stats for cube planer usage
private byte[] cubeSegmentStatisticsBytes;
{code}
 
h3. 
How it works


Before calling segment endpoint rpc, if the segment level cache is enabled, it will try to get the SegmentQueryResult from cache, if the result exist, directly return the result, else call the endpint rpc to get result, then save the result to cache for future usage. If the query result is very big, it will be chunked automatically.
The cache result will not be evicted explictly, it depends on the ttl configuration and LRU mechanism of the memcached, by default the ttl is set to 7 days.
h2. Performance


Since memcached performance is very good, it often takes 1-10 ms to get data from memcached, and don't need to do further aggregation/filter, so most of time the performance is better than HBase coprocessor rpc. Especially for the queries that need large aggregation/filter in the HBase region server, and no fuzzy key can be used, sometimes the performance has more than 10 times increase, below is some test result:

Query1:
select s1, s2, s3, s4, s5, s6, s7, s8, sum(pcount) c from shop_exp_path_analytics_flat where site_id = 0 AND device = 'Mobile' AND s5 = 'Checkout: Success' group by s1, s2, s3, s4, s5, s6, s7, s8

Below is some number for the query
total scan count: 2348
hit cuboid row count: 10,063,375
not use segment level cache: 2.247s
using segment level cache 0.16s

Query2:
hit cuboid row count: 800,317,603
Total scan count: 62347166
not use segment level cache: 12.823
use segment level cache: 0.519

Query3:
Total scan count: 64
Result row count: 58
not use segment level cache: 0.173
use segment level cache: 0.153

> Enable segment level query cache
> --------------------------------
>
>                 Key: KYLIN-2899
>                 URL: https://issues.apache.org/jira/browse/KYLIN-2899
>             Project: Kylin
>          Issue Type: Sub-task
>          Components: Query Engine
>    Affects Versions: v2.1.0
>            Reporter: Zhong Yanghong
>            Assignee: Ma Gang
>            Priority: Major
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)