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

Denis Magda reopened IGNITE-8873:
---------------------------------

[~ascherbakov], [~agoncharuk],

It's great to see that memory warmup is to be supported for the 
persistence-based deployments. But I would encourage us to move forward and 
reconsider the API from the usability standpoint.

As an end user, I don't understand how to use {code:java}loadPartition{code} 
method:
* How do I know which partition to preload? Should that be partition 5, 27 or 
876? Basically, how do I make a decision if a subset of the data has to be 
brought to RAM?
* What if I want to reload the whole table which is the most common requirement 
I've heard of? I'll be forced to have the calls like that:

{code:java}
foreach partition
loadPartition(partition)
{code}

Please let me know what you think about the following API that solves those 
usability points:
* {code:java}IgniteCache.loadCache{code} -> loads the whole table. Disregard 
the cases that it might not fit in RAM. Our users are smart. If there is not 
enough RAM then they can get more RAM space. 
* {code:java}IgniteCache.loadCache(predicate){code} -> for the scenarios when 
the system is designed in a way that RAM keeps a subset of data. For instance, 
users can load records for the last 5 days or for specific bank accounts. 

As for the {code:java}loadPartition{code} it doesn't look like a method that 
has to be at the public API level.

> Optimize cache scans with enabled persistence.
> ----------------------------------------------
>
>                 Key: IGNITE-8873
>                 URL: https://issues.apache.org/jira/browse/IGNITE-8873
>             Project: Ignite
>          Issue Type: Improvement
>            Reporter: Alexei Scherbakov
>            Assignee: Alexei Scherbakov
>            Priority: Major
>             Fix For: 2.8
>
>
> Currently cache scans with enabled persistence involve link resolution, which 
> can lead to radom disk access resulting in bad performace on SAS disks.
> One possibility is to preload cache data pages to remove slow random disk 
> access.



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

Reply via email to