[
https://issues.apache.org/jira/browse/HBASE-20429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16584616#comment-16584616
]
Zach York commented on HBASE-20429:
-----------------------------------
I was planning to starting work on some of this in a little bit, but I think we
need to decide whether we want to:
1) fix this in the FileSystem (not change HBase's assumption of a strongly
consistent FileSystem)
or
2) fix this in HBase where we know what we are doing with the data and any
guarantees needed.
Personally I think #2 will be easier, but would be willing to discuss. It might
end up being a mix of things.
Also, let's start with what currently is *not* working with HBase backed by S3
- what are the pain points we are trying to solve. That will help us direct the
effort better. I can definitely help where I can with that list.
> Support for mixed or write-heavy workloads on non-HDFS filesystems
> ------------------------------------------------------------------
>
> Key: HBASE-20429
> URL: https://issues.apache.org/jira/browse/HBASE-20429
> Project: HBase
> Issue Type: Umbrella
> Reporter: Andrew Purtell
> Priority: Major
>
> We can support reasonably well use cases on non-HDFS filesystems, like S3,
> where an external writer has loaded (and continues to load) HFiles via the
> bulk load mechanism, and then we serve out a read only workload at the HBase
> API.
> Mixed workloads or write-heavy workloads won't fare as well. In fact, data
> loss seems certain. It will depend in the specific filesystem, but all of the
> S3 backed Hadoop filesystems suffer from a couple of obvious problems,
> notably a lack of atomic rename.
> This umbrella will serve to collect some related ideas for consideration.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
