hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From lars hofhansl <lhofha...@yahoo.com>
Subject Re: Limited cross row transactions
Date Tue, 17 Jan 2012 22:54:22 GMT
Hey Ted,

I am trying not to prescribe a use case but to shoot for just enough building blocks that
it would be possible to do something like this without changing HBase code.
As it turns out after HBASE-5203 that is quite simple. To actually get it work would still
require a lot of coding and understanding in the client code, but at least it would be possible.
To implement the logic for a specific use case would be the onus of the client application.
In this case the client application/setup would be required to ensure that all rows participating
in a transaction are collocated in a single region. This is limiting, but will lead to efficient
transactions. Relaxing that should be a conscious choice by the client application.

Also (again following the Megastore story here), there can cheap local transactions and expensive
(2PC/Paxos) global transactions.
Even if global transactions existed (and I personally have my doubts here given the theoretical
limitations implied by the CAP theorem),
local transactions are still preferable and can the executed more efficiently.

-- Lars

----- Original Message -----
From: Ted Yu <yuzhihong@gmail.com>
To: dev@hbase.apache.org; lars hofhansl <lhofhansl@yahoo.com>
Sent: Tuesday, January 17, 2012 1:36 PM
Subject: Re: Limited cross row transactions

Can we collect use case for 'limited cross row transactions' first ?

I have been thinking about (unlimited) multi-row transaction support in
HBase. It may not be a one-man task. But we should definitely implement it


On Tue, Jan 17, 2012 at 1:27 PM, lars hofhansl <lhofhansl@yahoo.com> wrote:

> I just committed HBASE-5203 (together with HBASE-3584 this implements
> atomic row operations).
> Although a relatively small patch it lays the groundwork for heterogeneous
> operations in a single WALEdit.
> The interesting part is that even though the code enforced the atomic
> operation to be a for single row, this is not required.
> It is enough if all involved KVs reside in the same region.
> I am not saying that we should add any high level concept to HBase (such
> as the EntityGroups of Megastore).
> But, with a slight addition to the API (allowing a grouping of multiple
> row operations) client applications have all the building blocks to do
> limited cross row atomic operations.
> The client application would be responsible for either correctly
> pre-splitting the table, or a custom balancer has to be provided.
> The operation would fail if the regionserver determines that it would need
> data from multiple region servers.
> I think this needs at least minimal support from HBase and cannot
> (efficiently or without adding more moving parts) by a client API only.
> Comments? Is this worth pursuing? If so, I'll file a jira and provide a
> patch.
> Thanks.
> -- Lars

View raw message