hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Yu <yuzhih...@gmail.com>
Subject Re: Limited cross row transactions
Date Tue, 17 Jan 2012 21:49:54 GMT
Whether Omid fits the bill is open to discussion.

We should revisit HBASE-2315 and provide the support Flavio, et al need.

Cheers

On Tue, Jan 17, 2012 at 1:41 PM, Lars George <lars.george@gmail.com> wrote:

> Hi Ted,
>
> Wouldn't Omid (https://github.com/yahoo/omid) help there? Or is that too
> broad? Just curious.
>
> Lars
>
> On Jan 17, 2012, at 4:36 PM, Ted Yu wrote:
>
> > 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 <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
> >>
> >>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message