ignite-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mulugeta Mammo (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (IGNITE-6854) Enabling Persistent Memory for Ignite
Date Thu, 05 Jul 2018 15:12:00 GMT

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

Mulugeta Mammo updated IGNITE-6854:
    Attachment:     (was: ignite_3DXPoint.patch)

> Enabling Persistent Memory for Ignite
> -------------------------------------
>                 Key: IGNITE-6854
>                 URL: https://issues.apache.org/jira/browse/IGNITE-6854
>             Project: Ignite
>          Issue Type: New Feature
>    Affects Versions: 2.3
>            Reporter: Mulugeta Mammo
>            Priority: Major
>             Fix For: 2.7
> Ignite, when persistence mode is enabled, stores data and indexes on disk. To minimize
the latency of disks, several tuning options can be applied. Setting the page size of a memory
region to match the page size of the underlying storage, using a separate disk for the WAL,
and using production-level SSDs are just a few of them [ https://apacheignite.readme.io/docs/durable-memory-tuning#section-native-persistence-related-tuning
> A persistent memory store with low latency and high capacity offers a viable alternative
to disks. In light of this, we are proposing to make use of our Low Level Persistent Library
(LLPL), https://github.com/pmem/pcj/tree/master/LLPL, to offer a persistent memory storage
for Ignite. 
> At this point, we envision two distinct implementation options:
> # Data and indexes will continue to be stored in the off-heap memory but the disk will
be replaced by a persistent memory. Since persistence memory in this option is not a file
system, the logic currently offered by WAL file and the partition files would have to be implemented
from scratch.
> # In this option, we eliminate the current check-point process and the WAL file. We will
use a memory region defined by LLPL to store data and indexes. There will be no off-heap memory.
DRAM will be exclusively used to store hot cache entries just like the on-heap cache is in
the current implementation. 
> In both cases, there are more details and subtleties that have to handled – e.g. the
atomic and transactional guarantees offered. More clarifications will be given as we go along.

This message was sent by Atlassian JIRA

View raw message