Vladimir Ozerov created IGNITE-6934:
---------------------------------------
Summary: SQL: evaluate performance of onheap row caching
Key: IGNITE-6934
URL: https://issues.apache.org/jira/browse/IGNITE-6934
Project: Ignite
Issue Type: Task
Security Level: Public (Viewable by anyone)
Components: sql
Reporter: Vladimir Ozerov
Assignee: Taras Ledkov
Fix For: 2.4
Ignite has so-called "on heap cache" feature. When cache entry is accessed, we
copy it from offheap to heap and put it into a temporal concurrent hash map
[1], [2], where it resides during usage. When operation is finished, entry is
evicted. This is default behavior which keeps GC pressure low even for large
in-memory data sets.
The downside is that we loose time on copying from offheap to heap. To mitigate
this problem user can enable on-heap cache through
{{IgniteCache.onheapCacheEnabled}}. In this mode entry will not be evicted from
on-heap map, so it can be reused between different operations without
additional copying. Eviction rules are managed through eviction policy.
Unfortunately, SQL cannot use this optimization. As a result if key or value is
large enough, we loose a lot of time on memory copying. And we cannot use
current on-heap cache directly, we in SQL operate on row links, rather than on
keys. So to apply this optimization to SQL we should either create additional
row cache, or hack existing cache somehow.
As a first step I propose to evaluate the impact with quick and dirty solution:
1) Just add another map from link to K-V pair in the same cache, putting all
concurrency issues aside.
2) Use this cache from SQL engine.
3) Measure the impact.
[1] org.apache.ignite.internal.processors.cache.GridCacheConcurrentMapImpl
[2]
org.apache.ignite.internal.processors.cache.GridCacheConcurrentMap.CacheMapHolder
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
