ignite-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vladimir Ozerov (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (IGNITE-6934) SQL: evaluate performance of onheap row caching
Date Mon, 27 Nov 2017 20:08:00 GMT

     [ https://issues.apache.org/jira/browse/IGNITE-6934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Vladimir Ozerov resolved IGNITE-6934.
-------------------------------------
    Resolution: Won't Fix

No go for now. Correct long term solution will be focused on minimizing deserialization during
SQL execution.

> 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)

Mime
View raw message