[ 
https://issues.apache.org/jira/browse/HBASE-17018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15765286#comment-15765286
 ] 

Joep Rottinghuis commented on HBASE-17018:
------------------------------------------

[~devaraj] thanks for your feedback. Indeed I'm well aware that this feature 
may not make it into HBase if the consensus is indeed that this doesn't fit the 
intended core use-cases. I'm trying to keep the code separate so that it is 
relatively easy to pull out wholesale. For modifications of existing code I'll 
file separate sub-tasks.
Do you mind if I develop the code a little further here under the watchful eye 
of HBase gurus?

Also, would you have any suggestions how I should go about tackling sub-task 
HBASE-17327: "Allow for lazy connection / BufferedMutator creation"? I'm happy 
to do the work, but would like an opinion on the desired approach from HBase 
folks such as yourself.

> Spooling BufferedMutator
> ------------------------
>
>                 Key: HBASE-17018
>                 URL: https://issues.apache.org/jira/browse/HBASE-17018
>             Project: HBase
>          Issue Type: New Feature
>            Reporter: Joep Rottinghuis
>         Attachments: HBASE-17018.master.001.patch, 
> HBASE-17018.master.002.patch, HBASE-17018.master.003.patch, 
> HBASE-17018.master.004.patch, 
> HBASE-17018SpoolingBufferedMutatorDesign-v1.pdf, YARN-4061 HBase requirements 
> for fault tolerant writer.pdf
>
>
> For Yarn Timeline Service v2 we use HBase as a backing store.
> A big concern we would like to address is what to do if HBase is 
> (temporarily) down, for example in case of an HBase upgrade.
> Most of the high volume writes will be mostly on a best-effort basis, but 
> occasionally we do a flush. Mainly during application lifecycle events, 
> clients will call a flush on the timeline service API. In order to handle the 
> volume of writes we use a BufferedMutator. When flush gets called on our API, 
> we in turn call flush on the BufferedMutator.
> We would like our interface to HBase be able to spool the mutations to a 
> filesystems in case of HBase errors. If we use the Hadoop filesystem 
> interface, this can then be HDFS, gcs, s3, or any other distributed storage. 
> The mutations can then later be re-played, for example through a MapReduce 
> job.
> https://reviews.apache.org/r/54882/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to