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 22:22:33 GMT
People rely on RDBMS for the transaction support.

Consider the following example:
A highly de-normalized schema puts related users in the same region where
this 'limited cross row transactions' works.
After some time, the region has to be split (maybe due to good business
condition).
What should the HBase user do now ?

Cheers

On Tue, Jan 17, 2012 at 2:13 PM, Mikael Sitruk <mikael.sitruk@gmail.com>wrote:

> Ted - My 2 cents as a user.
> The user should know what he is doing, this is like a 'delete' operation,
> this is less intuitive that the original delete in RDBMS, so the same will
> be for this light transaction.
> If the transaction fails because of cross region server then the design of
> the user was wrong
> if the transaction fails because of concurrent access, then he should be
> able to re-read and reprocess its request.
> The only problem is how to make sure in advance that the different rows
> will be in the same RS?
>
> Lars - is the limitation is at the region or at the region server? It was
> not so clear.
>
> Mikael.S
>
> On Tue, Jan 17, 2012 at 11:52 PM, Ted Yu <yuzhihong@gmail.com> wrote:
>
> > Back to original proposal:
> > If client side grouping reveals that the batch of operations cannot be
> > supported by 'limited cross row transactions', what should the user do ?
> >
> > Cheers
> >
> > On Tue, Jan 17, 2012 at 1:49 PM, Ted Yu <yuzhihong@gmail.com> wrote:
> >
> > > 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
> > >> >>
> > >> >>
> > >>
> > >>
> > >
> >
>
>
>
> --
> Mikael.S
>

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