hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Enis Soztutar (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-10070) HBase read high-availability using timeline-consistent region replicas
Date Wed, 21 May 2014 20:36:43 GMT

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

Enis Soztutar commented on HBASE-10070:

bq. I believe the Yahoo PNUTS paper is where many have first heard the term 'timeline consistency'.
Daniel Abadi summarizes it at http://dbmsmusings.blogspot.com/2010/04/problems-with-cap-and-yahoos-little.html
as "where replicas may not be consistent with each other but updates are guaranteed to be
applied in the same order at all replicas", which I think is very concise. .... Might be good
to update the lead in to the timeline consistency part of the doc.
Agreed. Yes, the name was inspired by the PNUTS model. I like the concise form. I'll add it
to the doc. 
bq. we can define pluggable strategy on how to execute RPCs
The Consistency enum is mostly concerned about semantics, while execution layer (RPC) is concerned
about latency + performance. Even within a given Consistency model, you may want different
execution strategies I think (like for TIMELINE consistency, parallel and parallel with delay,
or go to first replica, then second, then third, etc). In the committed code in branch, the
consistency model implies hard coded execution model. 
bq. What happens if I ask for TIMELINE and cluster is not deployed with read replicas? Ignored
Good question. The execution strategy for TIMELINE replicas is to do the primary RPC first,
then if no response after some delay (10ms by default) do the RPCs for secondaries. If the
region has only 1 replica, there won't be any RPC, so it will just wait for the primary RPC
to response back.  

> HBase read high-availability using timeline-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 >
> 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

View raw message