hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Antonov (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-10070) HBase read high-availability using timeline-consistent region replicas
Date Thu, 22 May 2014 09:24:07 GMT

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

Mikhail Antonov commented on HBASE-10070:
-----------------------------------------

[~devaraj],  [~stack],  [~enis]

Yeah, the reason I brought it up is that unlike changes for example in LB, this is public
(yet evolving) API, so just wanted to double-check that we don't expose to client code details
which would limit us later.

bq. 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.
Sure, any consistency model (except current behavior i guess) would benefit from being customizable.

bq. So, rather than have the client ask for level of 'consistency' in the API, instead, the
replica interaction would be set on client construction dependent on the plugin supplied?
Either "rather" or "both", I guess. If we could say that level of consistency (strong, timeline
or quorum-strong) could be defined in config files per-client (not per-operations), we would
be able to avoid having this enum. But we consider that being able to define consistency level
per-operation is mandatory, right?

In that case I'm thinking of the following model:
 - deploy pluggable policy at client side which which decide on RPC requests, this policy
would be used globally for all requests as default
 - consider the Consistency enum (and point it out in both user and dev level docs) as a "hint",
used only to be able to customize individual scans or gets, and probably add note in class
documentation that cluster may ignore the flag set if the feature isn't available?
 - current timeline consistency model doesn't assume quorums for write, so I think it makes
sense to add QUORUM_STRONG in enum.
 
Thoughts?


> 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 >
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.2#6252)

Mime
View raw message