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 <[email protected]> To: [email protected]; lars hofhansl <[email protected]> Cc: 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 someday. Cheers On Tue, Jan 17, 2012 at 1:27 PM, lars hofhansl <[email protected]> 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 > >
