[jira] [Reopened] (IGNITE-8873) Optimize cache scans with enabled persistence.

["Denis Magda (JIRA)" <ji...@apache.org>]

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