[
https://issues.apache.org/jira/browse/HBASE-20952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16617877#comment-16617877
]
Sergey Soldatov commented on HBASE-20952:
-----------------------------------------
bq. However, when we think about hypothetical log systems, we could see an
optimization where the filtering of _just one Region's_ edits from a log can be
pushed down into the log system itself. Such a feature would remove the need
for WAL splitting to happen universally in HBase.
That's exactly I wanted to say. There are some cases where we don't need to
split WALs (WAL per RS model, streams with filters, etc). And the question is
whether we need to make any significant refactoring in this area (i.e., make
WALSplitter working with abstract WALs and creating new WALs). Or we may live
with the case where WALProvider has an interface to get recovered edits for the
particular region and for the current providers the result of the WALSplitter
will be returned, but for custom providers that would be implementation
specific.
> Re-visit the WAL API
> --------------------
>
> Key: HBASE-20952
> URL: https://issues.apache.org/jira/browse/HBASE-20952
> Project: HBase
> Issue Type: Sub-task
> Components: wal
> Reporter: Josh Elser
> Priority: Major
> Attachments: 20952.v1.txt
>
>
> Take a step back from the current WAL implementations and think about what an
> HBase WAL API should look like. What are the primitive calls that we require
> to guarantee durability of writes with a high degree of performance?
> The API needs to take the current implementations into consideration. We
> should also have a mind for what is happening in the Ratis LogService (but
> the LogService should not dictate what HBase's WAL API looks like RATIS-272).
> Other "systems" inside of HBase that use WALs are replication and
> backup&restore. Replication has the use-case for "tail"'ing the WAL which we
> should provide via our new API. B&R doesn't do anything fancy (IIRC). We
> should make sure all consumers are generally going to be OK with the API we
> create.
> The API may be "OK" (or OK in a part). We need to also consider other methods
> which were "bolted" on such as {{AbstractFSWAL}} and
> {{WALFileLengthProvider}}. Other corners of "WAL use" (like the
> {{WALSplitter}} should also be looked at to use WAL-APIs only).
> We also need to make sure that adequate interface audience and stability
> annotations are chosen.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
