[
https://issues.apache.org/jira/browse/IGNITE-6934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov closed IGNITE-6934.
-----------------------------------
> SQL: evaluate performance of onheap row caching
> -----------------------------------------------
>
> Key: IGNITE-6934
> URL: https://issues.apache.org/jira/browse/IGNITE-6934
> Project: Ignite
> Issue Type: Task
> Components: sql
> Reporter: Vladimir Ozerov
> Labels: performance
>
> 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)
