[
https://issues.apache.org/jira/browse/HBASE-10070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13872572#comment-13872572
]
stack commented on HBASE-10070:
-------------------------------
Here's a few comment on the JIRA content.
bq. In the present HBase architecture, it is hard, probably impossible, to
satisfy constraints like 99th percentile of the reads will be served under 10
ms.
Should this be an architectural objective for HBase? Just asking. Our
inspiration addressed the 99th percentile in a layer above.
bq. Of these, the detection is usually the longest and is presently in the
order of 20-30 seconds.
We should work on this for sure. Native zk client immune to JVM pause has come
up in the past. Would help all around (as per the Vladimir comment above)
bq. However, some clients will be better served if regions will be available
for reads during recovery for doing eventually consistent reads.
Radical! Our DNA up to this has been all about giving the application a
consistent view.
bq. For improving read availability, we propose a replicated read-only region
serving design, also referred as secondary regions, or region shadows.
Could this be build as a layer on top of HBase rather than alter HBase core
with shims on clients and CPs?
Do you envision this feature being always on? Or can it be disabled? If the
former (or latter actually), what implications for current read/write paths do
you see?
This is far along. I'm late to the game. Sorry about that. Let me take a
look at design and github.
> HBase read high-availability using eventually consistent region replicas
> ------------------------------------------------------------------------
>
> Key: HBASE-10070
> URL: https://issues.apache.org/jira/browse/HBASE-10070
> Project: HBase
> Issue Type: New Feature
> Reporter: Enis Soztutar
> Assignee: Enis Soztutar
> Attachments: HighAvailabilityDesignforreadsApachedoc.pdf
>
>
> In the present HBase architecture, it is hard, probably impossible, to
> satisfy constraints like 99th percentile of the reads will be served under 10
> ms. One of the major factors that affects this is the MTTR for regions. There
> are three phases in the MTTR process - detection, assignment, and recovery.
> Of these, the detection is usually the longest and is presently in the order
> of 20-30 seconds. During this time, the clients would not be able to read the
> region data.
> However, some clients will be better served if regions will be available for
> reads during recovery for doing eventually consistent reads. This will help
> with satisfying low latency guarantees for some class of applications which
> can work with stale reads.
> For improving read availability, we propose a replicated read-only region
> serving design, also referred as secondary regions, or region shadows.
> Extending current model of a region being opened for reads and writes in a
> single region server, the region will be also opened for reading in region
> servers. The region server which hosts the region for reads and writes (as in
> current case) will be declared as PRIMARY, while 0 or more region servers
> might be hosting the region as SECONDARY. There may be more than one
> secondary (replica count > 2).
> Will attach a design doc shortly which contains most of the details and some
> thoughts about development approaches. Reviews are more than welcome.
> We also have a proof of concept patch, which includes the master and regions
> server side of changes. Client side changes will be coming soon as well.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
