[
https://issues.apache.org/jira/browse/HIVE-13029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15235514#comment-15235514
]
Sergey Shelukhin commented on HIVE-13029:
-----------------------------------------
Hmm. The patch basically looks good to me. {noformat} // truncate (TODO:
posix_fallocate?){noformat} should this be addressed, or followed up on?
Is the assumption that we don't need to use explicit memory cache at all if we
can memory map the fast storage?
In that case, is the usage pattern such that we configure cache to be larger
than RAM and let OS page stuff in/out?
I was assuming there will be a 2-tiered cache, although the patch is very
elegant, I do have to say ;)
The SSD cache would require the 2-tiered cache, wouldn't it?
I also wonder if, once the metadata cache is moved off-heap, it would need a
separate allocator to ensure it's in memory.
> NVDIMM support for LLAP Cache
> -----------------------------
>
> Key: HIVE-13029
> URL: https://issues.apache.org/jira/browse/HIVE-13029
> Project: Hive
> Issue Type: New Feature
> Components: llap
> Affects Versions: 2.1.0
> Reporter: Gopal V
> Assignee: Gopal V
> Priority: Critical
> Attachments: HIVE-13029.1.patch
>
>
> LLAP cache has been designed so that the cache can be offloaded easily to a
> pmem API without restart coherence.
> The tricky part about NVDIMMs are restart coherence, while most of the cache
> gains can be obtained without keeping state across refreshes, since LLAP is
> not the system of record, HDFS is.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
