[
https://issues.apache.org/jira/browse/HBASE-10070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13872752#comment-13872752
]
stack commented on HBASE-10070:
-------------------------------
Feedback on the design:
"...some clients will be better served if regions will be available for reads
during recovery for doing eventually consistent reads"
Has anyone asked for this feature on the list or in issues? You have a hard
user for this feature or is this speculative work? If so, is the user/customer
looking explicitly to be able to do stale reads or is giving them stale data a
compromise on what they are actually asking for (Let me guess, HA consistent
view). If HA consistent view is what they want, should we work on that instead?
What delivery timeline are we talking? Is this is for 1.0 hbase? Or is it
post 1.0? If the later, maybe we want to go more radical than what is being
proposed here.
bq. However, some clients will be better served if regions will be available
for reads during recovery for doing eventually consistent reads.
Should such clients use another data store, one that allows eventually
consistent views? Clients having to deal with sometimes stale data will be
more involved (I like this deduction from the F1 paper "Designing applications
to cope with concurrency anomalies in their data is very error-prone,
time-consuming, and ultimately not worth the performance gains").
Pardon all the questions. I am concerned that a prime directive, consistent
view, is being softened. As is, its easy saying what we are. Going forward,
lets not get to a spot where we have to answer "It is complicated..." when
asked if we are a consistent store or not.
This document is nicely written.
Here are some random comments as I go through the doc:
+ Could we implement this feature with some minor changes in core and then
stuff like clients that can do the read replica dance done as subclass of
current client -- a read replica client -- or at a layer above current client?
+ Why notions of secondary and tertiary? Isn't it primary and replica only?
+ "Two region replicas cannot be hosted at the same RS (hard)" If RS count is
< # of replicas, this is relaxed I'm sure (hard becomes soft). Hmm... this
seems complicated: "If LB cannot assign secondary replicas due to above hard
constraints, the replica will be added to this map. In case of new region
servers joining the cluster, LB will be invoked over this map." Suggest
dropping it for first cut.
+ Seems wrong having RCP consious of replicas. I'd think this managed at
higher levels up in HCM.
This design looks viable to me and the document is of good quality.
> 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)
