[
https://issues.apache.org/jira/browse/HBASE-16417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15661784#comment-15661784
]
Anoop Sam John commented on HBASE-16417:
----------------------------------------
bq.4. Change read (get) implementation to first seek for the key in memstore(s)
only, and only if no matching entry is found seek in all memstore segments and
all relevant store files. This could be a subject of another Jira. We believe
this would be beneficial also with no compaction, and even more when
index-/data-compaction is employed. Any thought on this direction
There are few issues for this. When we do a get for a row, memstore+HFiles read
happens per cf wise. But how we can know all possible qualifiers in that. My Q
is when we able to find an entry for the rk in memstore, how we can be sure
that there are no other entries for this rk in HFiles? So suppose there are
qualifiers also mentioned in the Get, (Get#addColumn(byte [] family, byte []
qualifier)) then also even if we read all qualifiers from memstore itself, how
we know there are no other versions of this in other HFiles. U can see there is
an InternalScan extension for Scan where one can say use memstore only or not.
But am getting what u r saying is bit diff. So this can be done with certain
hard limitations. Only version should be present and/or ts on puts are always
increasing. Gets are issues with columns and/or while doing writes all columns
of a CF are put together. Just noting down whatever comes at first thought.
> In-Memory MemStore Policy for Flattening and Compactions
> --------------------------------------------------------
>
> Key: HBASE-16417
> URL: https://issues.apache.org/jira/browse/HBASE-16417
> Project: HBase
> Issue Type: Sub-task
> Reporter: Anastasia Braginsky
> Assignee: Eshcar Hillel
> Fix For: 2.0.0
>
> Attachments: HBASE-16417-benchmarkresults-20161101.pdf,
> HBASE-16417-benchmarkresults-20161110.pdf
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
