[
https://issues.apache.org/jira/browse/HBASE-16417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15662097#comment-15662097
]
Eshcar Hillel commented on HBASE-16417:
---------------------------------------
bq. then also even if we read all qualifiers from memstore itself, how we know
there are no other versions of this in other HFiles.
I think I understand. So it is not enough just to check after the first
(memstores scan) round that the result is not empty -- we need to go on and
check that we retrieved data for all qualifiers in the get query, and if not do
the second round which seeks the other Hfile. any problem with this?
bq. U can see there is an InternalScan extension for Scan where one can say use
memstore only or not.
I am not familiar with this internal scanner. Where/when is it being used?
bq. So this can be done with certain hard limitations. Only version should be
present and/or ts on puts are always increasing.
Yes, if the application manipulates ts so that it is not always increasing you
have a point. Is there a way to know this for sure? I don't think so.
Bottom line, [~anoop.hbase] you raise some valid concerns. So it might be that
we cannot apply this optimization for all cases, however I am confident that
99.99% of the application can benefit from such optimization, it is highly
unreasonable not to apply it just to allow corner cases like manipulating
timestamps.
Could we have the application "announce" that it is manipulating ts so then we
avoid this optimization but apply it in all other common cases (?)
> 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)
