[
https://issues.apache.org/jira/browse/HBASE-3498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12989475#comment-12989475
]
ryan rawson commented on HBASE-3498:
------------------------------------
The current memstore does not exhibit the require behavior because it is just a
flat sequence of KVs, with no understanding of 'row' or 'between a row'. This
means as you are iterating through, the StoreScanner will find the 'next' row
and will halt scanning for that row, leaving the memstore scanner pointing to
the next row. Now other writing threads have a chance to insert KVs between the
current KV and the 'previous' KV which was just scanned out. This has 2 major
problems:
- we could miss a row, and not be as live as we want. This seems kind of
academic, but can have real consequences in the META scanner in the master.
- we might miss new columns, or version of columns, on the current row. Thus
when we read the next row we MISS data returning a partial read to the
StoreScanner that can only be fixed by pruning back how 'current' we are in
terms of which KV.memstoreTS to include. This has different problems for
HBASE-2856.
> Memstore scanner needs new semantics, which may require new data structure
> --------------------------------------------------------------------------
>
> Key: HBASE-3498
> URL: https://issues.apache.org/jira/browse/HBASE-3498
> Project: HBase
> Issue Type: Sub-task
> Reporter: ryan rawson
> Assignee: ryan rawson
> Fix For: 0.92.0
>
>
> We may need a new memstore datastructure. Much has been written about the
> concurrency and speed and cpu usage, but there are new things that were
> brought to light with HBASE-2856.
> Specifically we need a memstore scanner that serves up to the moment reads,
> with a row-level completeness. Specifically after a memstore scanner goes
> past the end of a row, it should return some kind of 'end of row' token which
> the StoreScanner should trigger on to know it's at the end of the row. The
> next call to memstore scanner.next() should return the _very next available
> row from the start of that row_ at _the time it's requested_.
> It should specifically NOT:
> - return everything but the first column
> - skip a row that was inserted _after_ the previous next() was completed
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
