I would also add that if you need an "always available" store (as in you want A and P of CAP , and can sacrifice C),
you might be better served with one of the DynamoDB inspired architectures such as Riak or Cassandra. HBase choses C and P of CAP.
It might seem strange that as an HBase committer I would advise to look at some non-HBase technology, but I am a big fan of using the right tool for the right job.
1. See also http://en.wikipedia.org/wiki/CAP_theorem
From: Jean-Daniel Cryans <[EMAIL PROTECTED]>
To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
Sent: Thursday, April 25, 2013 10:17 AM
Subject: Re: HBase - prioritizing writes over reads?
Short answer is no, there's no knob or configuration to do that.
Longer answer is it depends. Are the reads and writes going to different
regions/tables? If so, disable the balancer and take it in charge
by segregating the offending regions on their own RS.
I also see you have the requirement to take incoming data not matter what.
Well, this currently cannot be guaranteed in HBase since a RS failure will
incur some limited unavailability while the ZK session times out, the logs
are replayed and the regions are reassigned. I don't know what kind of SLA
you have but it sounds like even without your reads problem you need to do
something client-side to take care of this. Local buffers maybe? It would
work as long as you don't need to serve that new data right away (unless
you also start serving from the local buffer, but it's getting complicated).
Hope this helps,
On Wed, Apr 24, 2013 at 3:25 AM, kzurek <[EMAIL PROTECTED]> wrote:
> Is it possible to prioritize writes over reads in HBase? I'm facing some
> read related issues that influence my write clients and cluster in general
> (constantly growing store files on some RS). Due to the fact that I cannot
> let myself to loose/skip incoming data, I would like to guarantee that in
> case of extensive read I will be able to limit incoming read requests, so
> that write requests wont be influenced. Is it possible? If so what would be
> the best way to that and where it should be placed - on the client or
> cluster side)?
> View this message in context:
> Sent from the HBase User mailing list archive at Nabble.com.