You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hbase.apache.org by lars hofhansl <lh...@yahoo.com> on 2012/01/17 22:27:12 UTC
Limited cross row transactions
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
Re: Limited cross row transactions
Posted by lars hofhansl <lh...@yahoo.com>.
Yes. Although the app should set it up so that this does not happen (presplitting and avoid future splitting, or a custom balancer), because it means the same transaction the next time would need to fail.
Lemme just file the jira and provide the patch. It'll be small (will do it today or tomorrow), and then we can discuss there.
----- Original Message -----
From: Stack <st...@duboce.net>
To: dev@hbase.apache.org; lars hofhansl <lh...@yahoo.com>
Cc:
Sent: Tuesday, January 17, 2012 2:23 PM
Subject: Re: Limited cross row transactions
On Tue, Jan 17, 2012 at 1:27 PM, lars hofhansl <lh...@yahoo.com> wrote:
> 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.
>
So, if a region split post the commit of this x-row transaction, it'd
be ok? Or we should just do entity groups altogether and not let
region splits happen in middle of an 'entity group'; i.e. we'd split
only where the Nth byte of a key changes?
St.Ack
Re: Limited cross row transactions
Posted by Stack <st...@duboce.net>.
On Tue, Jan 17, 2012 at 1:27 PM, lars hofhansl <lh...@yahoo.com> wrote:
> 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.
>
So, if a region split post the commit of this x-row transaction, it'd
be ok? Or we should just do entity groups altogether and not let
region splits happen in middle of an 'entity group'; i.e. we'd split
only where the Nth byte of a key changes?
St.Ack
Re: Limited cross row transactions
Posted by Jesse Yates <je...@gmail.com>.
Lars,
This sounds pretty cool. I'd be all for it.
+1 for leveraging up most of the existing features.
Do I sense a megastore implementation side project somewhere in the future?
- Jesse Yates
Sent from my iPhone.
On Jan 17, 2012, at 1:27 PM, lars hofhansl <lh...@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
>
Re: Limited cross row transactions
Posted by Mikael Sitruk <mi...@gmail.com>.
cross rows transaction (even limited) is a feature lot of people are
requiring, support is greatly appreciated.
+1
Mikael.S
On Tue, Jan 17, 2012 at 11:31 PM, Lars George <la...@gmail.com> wrote:
> Sounds sweet Lars!
>
> On Jan 17, 2012, at 4:27 PM, lars hofhansl 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
Re: Limited cross row transactions
Posted by Lars George <la...@gmail.com>.
Sounds sweet Lars!
On Jan 17, 2012, at 4:27 PM, lars hofhansl 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
>
Re: Limited cross row transactions
Posted by Jesse Yates <je...@gmail.com>.
There is probably some pretty simple logic involved in figuring out if a
given set of operations can be supported (though maybe we can make that so
you can dynamically load your own checker as well). At best this checking
would execute on the client-side and worst case on the region-servers (or
secondary mechanism) and then throw an UnsupportedOperationException if its
not allowed.
If the user gets this exception they should (1) have an alternative put
strategy when the client throws this error, or (2)allow it to drop on the
floor (and probably log it on their own system). In production you should
have pretty good bounds on what is happening, so unsupported operations
really should be exceptional.
At least that was the easiest way I could see to support it.
-------------------
Jesse Yates
240-888-2200
@jesse_yates
jyates.github.com
On Tue, Jan 17, 2012 at 1:52 PM, Ted Yu <yu...@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 <yu...@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 <lh...@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
> >> >>
> >> >>
> >>
> >>
> >
>
Re: Limited cross row transactions
Posted by lars hofhansl <lh...@yahoo.com>.
You are right that Megastore maps multiple tables into a single BigTable row.
I was referring to the handling of indexes (which does use a separate row key for each index entry in Megastore).
So with HBASE-5203 it is already possible to model something like parent/child transactions (minus the indexing at least). Cool... :)
If we had smarter startRow placement for scanners (on column boundaries), even consistent indexes could handled inside a single row.
----- Original Message -----
From: Matt Corgan <mc...@hotpads.com>
To: dev@hbase.apache.org
Cc: lars hofhansl <lh...@yahoo.com>
Sent: Tuesday, January 17, 2012 5:15 PM
Subject: Re: Limited cross row transactions
>
> one could have a table that hosts a parent child relationship in a single
> table, by prefixing all child child row keys with the parent row key,
> Now it is possible to presplit the table (or use a custom local balancer)
> so that child rows are always in the same region as the parent rows.
I thought BigTable/Megastore handled this kind of thing by putting
everything into a single row with the entity group id as the hbase rowKey.
Then you add all parent and child values to the same hbase row by pushing
their original row keys into the qualifiers. You build the qualifiers by
concatenating the table name with the original row key.
HBase should handle the arbitrarily wide rows and prevent the row from
splitting between regions. Having the table name as a prefix of each
qualifier adds a lot of metadata, but good prefix compression should
eliminate that.
On Tue, Jan 17, 2012 at 4:57 PM, Ted Yu <yu...@gmail.com> wrote:
> >> so that child rows are always in the same region as the parent rows
> Should the user expect abnormal growth for certain parent(s) ?
>
> I think even HFile v2 has a limit on the file size beyond which operations
> would become less efficient.
>
> On Tue, Jan 17, 2012 at 4:48 PM, lars hofhansl <lh...@yahoo.com>
> wrote:
>
> > Yes, it's hard constraint, but the building blocks are there.
> > User can disable automatic splitting and pre-split the table.
> >
> > For example one could have a table that hosts a parent child relationship
> > in a single table, by prefixing all child child row keys with the parent
> > row key,
> > Now it is possible to presplit the table (or use a custom local balancer)
> > so that child rows are always in the same region as the parent rows.
> > And then it would be possible to do cross parent/child transactions.
> >
> > Using the same scheme it is possible to do consistent parent/child
> indexes
> > (consistent indexes within the same parent prefix).
> > (I just made this up, but this is somewhat similar to the Megastore
> > design, I think)
> >
> >
> > Anyway, I set out asking whether this would be a useful endeavor, seems
> > the answer is resounding "maybe". :)
> >
> >
> > -- Lars
> >
> >
> >
> > ----- Original Message -----
> > From: Mikael Sitruk <mi...@gmail.com>
> > To: dev@hbase.apache.org
> > Cc:
> > Sent: Tuesday, January 17, 2012 3:07 PM
> > Subject: Re: Limited cross row transactions
> >
> > Well i understand the limitation now, asking to be in the same region is
> > really hard constraint.
> > Even if this is on the same RS this is not enough, because after a
> restart,
> > regions may be allocated differently and now part of the data may be in
> one
> > region under server A and the other part under server B.
> >
> > Well perhaps we need use case for better understanding, and perhaps
> finding
> > alternative.
> >
> > The first use case i was thinking of is as follow -
> > I need to insert data with different access criteria, but the data
> inserted
> > should be inserted in atomic way.
> > In RDBMS i would have two table, insert data in the first one with key#1
> > and then in the second one with key #2 then commit.
> > In HBase i need to use different column family with key #1 (for
> atomicity)
> > then to manage a kind of secondary index to map key#2 to key #1 (perhaps
> > via co-processor) to have quick access to the data of key#2.
> > Having cross row trx, i would think of sing different keys under the same
> > table (and probably different cf too), without the need to have secondary
> > index, but again with the limitation it does not seems to be easily
> > feasible.
> >
> > Mik.
> >
> > On Wed, Jan 18, 2012 at 12:22 AM, Ted Yu <yu...@gmail.com> wrote:
> >
> > > 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 <yu...@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 <yu...@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
> > > >
> > >
> >
> >
> >
> > --
> > Mikael.S
> >
> >
>
Re: Limited cross row transactions
Posted by Matt Corgan <mc...@hotpads.com>.
>
> one could have a table that hosts a parent child relationship in a single
> table, by prefixing all child child row keys with the parent row key,
> Now it is possible to presplit the table (or use a custom local balancer)
> so that child rows are always in the same region as the parent rows.
I thought BigTable/Megastore handled this kind of thing by putting
everything into a single row with the entity group id as the hbase rowKey.
Then you add all parent and child values to the same hbase row by pushing
their original row keys into the qualifiers. You build the qualifiers by
concatenating the table name with the original row key.
HBase should handle the arbitrarily wide rows and prevent the row from
splitting between regions. Having the table name as a prefix of each
qualifier adds a lot of metadata, but good prefix compression should
eliminate that.
On Tue, Jan 17, 2012 at 4:57 PM, Ted Yu <yu...@gmail.com> wrote:
> >> so that child rows are always in the same region as the parent rows
> Should the user expect abnormal growth for certain parent(s) ?
>
> I think even HFile v2 has a limit on the file size beyond which operations
> would become less efficient.
>
> On Tue, Jan 17, 2012 at 4:48 PM, lars hofhansl <lh...@yahoo.com>
> wrote:
>
> > Yes, it's hard constraint, but the building blocks are there.
> > User can disable automatic splitting and pre-split the table.
> >
> > For example one could have a table that hosts a parent child relationship
> > in a single table, by prefixing all child child row keys with the parent
> > row key,
> > Now it is possible to presplit the table (or use a custom local balancer)
> > so that child rows are always in the same region as the parent rows.
> > And then it would be possible to do cross parent/child transactions.
> >
> > Using the same scheme it is possible to do consistent parent/child
> indexes
> > (consistent indexes within the same parent prefix).
> > (I just made this up, but this is somewhat similar to the Megastore
> > design, I think)
> >
> >
> > Anyway, I set out asking whether this would be a useful endeavor, seems
> > the answer is resounding "maybe". :)
> >
> >
> > -- Lars
> >
> >
> >
> > ----- Original Message -----
> > From: Mikael Sitruk <mi...@gmail.com>
> > To: dev@hbase.apache.org
> > Cc:
> > Sent: Tuesday, January 17, 2012 3:07 PM
> > Subject: Re: Limited cross row transactions
> >
> > Well i understand the limitation now, asking to be in the same region is
> > really hard constraint.
> > Even if this is on the same RS this is not enough, because after a
> restart,
> > regions may be allocated differently and now part of the data may be in
> one
> > region under server A and the other part under server B.
> >
> > Well perhaps we need use case for better understanding, and perhaps
> finding
> > alternative.
> >
> > The first use case i was thinking of is as follow -
> > I need to insert data with different access criteria, but the data
> inserted
> > should be inserted in atomic way.
> > In RDBMS i would have two table, insert data in the first one with key#1
> > and then in the second one with key #2 then commit.
> > In HBase i need to use different column family with key #1 (for
> atomicity)
> > then to manage a kind of secondary index to map key#2 to key #1 (perhaps
> > via co-processor) to have quick access to the data of key#2.
> > Having cross row trx, i would think of sing different keys under the same
> > table (and probably different cf too), without the need to have secondary
> > index, but again with the limitation it does not seems to be easily
> > feasible.
> >
> > Mik.
> >
> > On Wed, Jan 18, 2012 at 12:22 AM, Ted Yu <yu...@gmail.com> wrote:
> >
> > > 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 <yu...@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 <yu...@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
> > > >
> > >
> >
> >
> >
> > --
> > Mikael.S
> >
> >
>
Re: Limited cross row transactions
Posted by lars hofhansl <lh...@yahoo.com>.
True. That the nature of the beast, though.
Either you collocate the data and can do fast local transactions or you do distributed transactions with all their implications.
Because of the different performance implications you wouldn't want to have this decision made automatically.
----- Original Message -----
From: Ted Yu <yu...@gmail.com>
To: dev@hbase.apache.org; lars hofhansl <lh...@yahoo.com>
Cc:
Sent: Tuesday, January 17, 2012 4:57 PM
Subject: Re: Limited cross row transactions
>> so that child rows are always in the same region as the parent rows
Should the user expect abnormal growth for certain parent(s) ?
I think even HFile v2 has a limit on the file size beyond which operations
would become less efficient.
On Tue, Jan 17, 2012 at 4:48 PM, lars hofhansl <lh...@yahoo.com> wrote:
> Yes, it's hard constraint, but the building blocks are there.
> User can disable automatic splitting and pre-split the table.
>
> For example one could have a table that hosts a parent child relationship
> in a single table, by prefixing all child child row keys with the parent
> row key,
> Now it is possible to presplit the table (or use a custom local balancer)
> so that child rows are always in the same region as the parent rows.
> And then it would be possible to do cross parent/child transactions.
>
> Using the same scheme it is possible to do consistent parent/child indexes
> (consistent indexes within the same parent prefix).
> (I just made this up, but this is somewhat similar to the Megastore
> design, I think)
>
>
> Anyway, I set out asking whether this would be a useful endeavor, seems
> the answer is resounding "maybe". :)
>
>
> -- Lars
>
>
>
> ----- Original Message -----
> From: Mikael Sitruk <mi...@gmail.com>
> To: dev@hbase.apache.org
> Cc:
> Sent: Tuesday, January 17, 2012 3:07 PM
> Subject: Re: Limited cross row transactions
>
> Well i understand the limitation now, asking to be in the same region is
> really hard constraint.
> Even if this is on the same RS this is not enough, because after a restart,
> regions may be allocated differently and now part of the data may be in one
> region under server A and the other part under server B.
>
> Well perhaps we need use case for better understanding, and perhaps finding
> alternative.
>
> The first use case i was thinking of is as follow -
> I need to insert data with different access criteria, but the data inserted
> should be inserted in atomic way.
> In RDBMS i would have two table, insert data in the first one with key#1
> and then in the second one with key #2 then commit.
> In HBase i need to use different column family with key #1 (for atomicity)
> then to manage a kind of secondary index to map key#2 to key #1 (perhaps
> via co-processor) to have quick access to the data of key#2.
> Having cross row trx, i would think of sing different keys under the same
> table (and probably different cf too), without the need to have secondary
> index, but again with the limitation it does not seems to be easily
> feasible.
>
> Mik.
>
> On Wed, Jan 18, 2012 at 12:22 AM, Ted Yu <yu...@gmail.com> wrote:
>
> > 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 <yu...@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 <yu...@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
> > >
> >
>
>
>
> --
> Mikael.S
>
>
Re: Limited cross row transactions
Posted by Ted Yu <yu...@gmail.com>.
>> so that child rows are always in the same region as the parent rows
Should the user expect abnormal growth for certain parent(s) ?
I think even HFile v2 has a limit on the file size beyond which operations
would become less efficient.
On Tue, Jan 17, 2012 at 4:48 PM, lars hofhansl <lh...@yahoo.com> wrote:
> Yes, it's hard constraint, but the building blocks are there.
> User can disable automatic splitting and pre-split the table.
>
> For example one could have a table that hosts a parent child relationship
> in a single table, by prefixing all child child row keys with the parent
> row key,
> Now it is possible to presplit the table (or use a custom local balancer)
> so that child rows are always in the same region as the parent rows.
> And then it would be possible to do cross parent/child transactions.
>
> Using the same scheme it is possible to do consistent parent/child indexes
> (consistent indexes within the same parent prefix).
> (I just made this up, but this is somewhat similar to the Megastore
> design, I think)
>
>
> Anyway, I set out asking whether this would be a useful endeavor, seems
> the answer is resounding "maybe". :)
>
>
> -- Lars
>
>
>
> ----- Original Message -----
> From: Mikael Sitruk <mi...@gmail.com>
> To: dev@hbase.apache.org
> Cc:
> Sent: Tuesday, January 17, 2012 3:07 PM
> Subject: Re: Limited cross row transactions
>
> Well i understand the limitation now, asking to be in the same region is
> really hard constraint.
> Even if this is on the same RS this is not enough, because after a restart,
> regions may be allocated differently and now part of the data may be in one
> region under server A and the other part under server B.
>
> Well perhaps we need use case for better understanding, and perhaps finding
> alternative.
>
> The first use case i was thinking of is as follow -
> I need to insert data with different access criteria, but the data inserted
> should be inserted in atomic way.
> In RDBMS i would have two table, insert data in the first one with key#1
> and then in the second one with key #2 then commit.
> In HBase i need to use different column family with key #1 (for atomicity)
> then to manage a kind of secondary index to map key#2 to key #1 (perhaps
> via co-processor) to have quick access to the data of key#2.
> Having cross row trx, i would think of sing different keys under the same
> table (and probably different cf too), without the need to have secondary
> index, but again with the limitation it does not seems to be easily
> feasible.
>
> Mik.
>
> On Wed, Jan 18, 2012 at 12:22 AM, Ted Yu <yu...@gmail.com> wrote:
>
> > 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 <yu...@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 <yu...@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
> > >
> >
>
>
>
> --
> Mikael.S
>
>
Re: Limited cross row transactions
Posted by lars hofhansl <lh...@yahoo.com>.
Yes, it's hard constraint, but the building blocks are there.
User can disable automatic splitting and pre-split the table.
For example one could have a table that hosts a parent child relationship in a single table, by prefixing all child child row keys with the parent row key,
Now it is possible to presplit the table (or use a custom local balancer) so that child rows are always in the same region as the parent rows.
And then it would be possible to do cross parent/child transactions.
Using the same scheme it is possible to do consistent parent/child indexes (consistent indexes within the same parent prefix).
(I just made this up, but this is somewhat similar to the Megastore design, I think)
Anyway, I set out asking whether this would be a useful endeavor, seems the answer is resounding "maybe". :)
-- Lars
----- Original Message -----
From: Mikael Sitruk <mi...@gmail.com>
To: dev@hbase.apache.org
Cc:
Sent: Tuesday, January 17, 2012 3:07 PM
Subject: Re: Limited cross row transactions
Well i understand the limitation now, asking to be in the same region is
really hard constraint.
Even if this is on the same RS this is not enough, because after a restart,
regions may be allocated differently and now part of the data may be in one
region under server A and the other part under server B.
Well perhaps we need use case for better understanding, and perhaps finding
alternative.
The first use case i was thinking of is as follow -
I need to insert data with different access criteria, but the data inserted
should be inserted in atomic way.
In RDBMS i would have two table, insert data in the first one with key#1
and then in the second one with key #2 then commit.
In HBase i need to use different column family with key #1 (for atomicity)
then to manage a kind of secondary index to map key#2 to key #1 (perhaps
via co-processor) to have quick access to the data of key#2.
Having cross row trx, i would think of sing different keys under the same
table (and probably different cf too), without the need to have secondary
index, but again with the limitation it does not seems to be easily
feasible.
Mik.
On Wed, Jan 18, 2012 at 12:22 AM, Ted Yu <yu...@gmail.com> wrote:
> 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 <yu...@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 <yu...@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
> >
>
--
Mikael.S
Re: Limited cross row transactions
Posted by lars hofhansl <lh...@yahoo.com>.
A quick followup...
This is now committed as a "developer feature". That means it is not exposed via HTable or any other standard client interface.
Instead it exposes as a general hook that coprocessor endpoints can call.
Coprocessor endpoints are (1) already region aware and (2) also had the ability to modify mutliple rows (but weren't able to do efficiently or correctly; said hook just makes it possible).
Along with HBASE-5304, which makes RegionSplitPolicy more accessible, this provides all part for cheap *local* transactions.
A sample KeyPrefixRegionSplitPolicy and a MultiRowMutationEndpoint are shipped with HBase.
This blog post explains how one could use this: http://hadoop-hbase.blogspot.com/2012/02/limited-cross-row-transactions-in-hbase.html
Now, let's add 2nd'ary indexes and global transactions :)
-- Lars
________________________________
From: lars hofhansl <lh...@yahoo.com>
To: "dev@hbase.apache.org" <de...@hbase.apache.org>
Sent: Wednesday, January 18, 2012 5:02 PM
Subject: Re: Limited cross row transactions
Filed https://issues.apache.org/jira/browse/HBASE-5229 for further discussion, attached a patch that does this.
As for your point...
The below is one way to define limited groups of rows that can participate in transactions (I should not have named it parent/child, that just confuses my point).
Your scenario calls for global transaction (unless you have to some other approach to limit the scope of rows that could participate in your FK transactions to something less than the entire database).
If every transaction is a global transaction the database will not scale.
See http://www.julianbrowne.com/article/viewer/brewers-cap-theorem
and http://www.cloudera.com/blog/2010/04/cap-confusion-problems-with-partition-tolerance/
Also check out two phase commit failure and blocking scenarios, and Paxos' conditions for termination.
-- Lars
----- Original Message -----
From: Mikael Sitruk <mi...@gmail.com>
To: dev@hbase.apache.org; lars hofhansl <lh...@yahoo.com>
Cc:
Sent: Wednesday, January 18, 2012 12:01 AM
Subject: Re: Limited cross row transactions
This is for parent child relationship, but what if there is no parent child
relationship, but more a foreign key like relationship?
Using this model you do a full scan to get all the index (since you don't
know the parent, you just know the "secondary index").
Or will you use a group ID as a prefix of parent key and "child" key? In
this case splitting according to group may be more difficult, (due to
different growth of groups).
Doing this aren't we back in the headache of sharding in rdbms?
Mikael.S
On Wed, Jan 18, 2012 at 7:45 AM, lars hofhansl <lh...@yahoo.com> wrote:
> This thread is probably getting too long...
>
> In HBase we have to let go of "global stuff". I submit that global
> transactions across 1000's of nodes that can fail will never work
> adequately.
> For that kind of consistency you will be hit in availability.
>
> Like Megastore the trick is in creating a local grouping of entities that
> can participate in local transactions.
> If you limit the (consistent) index to child entities of parent entity you
> can form your index like this:
> parentKey1...
> parentKey1.childTableName1.indexedField1
> parentKey1.childTableName1.indexedField2
> ...
> parentKey1.childTableName2.indexedField1
> parentKey1.childTableName2.indexedField2
> ...
> (assuming . cannot be in any parent key or child table name here, but you
> get the idea).
>
>
> When scanning the parent you'd have to skip the index rows with a filter.
> Within a parentKey you can find childKeys efficiently by scanning the
> index rows.
>
> Since the parent and the index entries would sort together the table can
> be pre-split (or one could have a simple prefix based balancer).
>
> -- Lars
>
> ----- Original Message -----
> From: Mikael Sitruk <mi...@gmail.com>
> To: dev@hbase.apache.org
> Cc:
> Sent: Tuesday, January 17, 2012 3:07 PM
> Subject: Re: Limited cross row transactions
>
> Well i understand the limitation now, asking to be in the same region is
> really hard constraint.
> Even if this is on the same RS this is not enough, because after a restart,
> regions may be allocated differently and now part of the data may be in one
> region under server A and the other part under server B.
>
> Well perhaps we need use case for better understanding, and perhaps finding
> alternative.
>
> The first use case i was thinking of is as follow -
> I need to insert data with different access criteria, but the data inserted
> should be inserted in atomic way.
> In RDBMS i would have two table, insert data in the first one with key#1
> and then in the second one with key #2 then commit.
> In HBase i need to use different column family with key #1 (for atomicity)
> then to manage a kind of secondary index to map key#2 to key #1 (perhaps
> via co-processor) to have quick access to the data of key#2.
> Having cross row trx, i would think of sing different keys under the same
> table (and probably different cf too), without the need to have secondary
> index, but again with the limitation it does not seems to be easily
> feasible.
>
> Mik.
>
> On Wed, Jan 18, 2012 at 12:22 AM, Ted Yu <yu...@gmail.com> wrote:
>
> > 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 <yu...@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 <yu...@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
> > >
> >
>
>
>
> --
> Mikael.S
>
>
--
Mikael.S
Re: Limited cross row transactions
Posted by lars hofhansl <lh...@yahoo.com>.
This is a good point Todd. The best so far that I have heard against doing this.
Can you comment on the jira?
-- Lars
________________________________
From: Todd Lipcon <to...@cloudera.com>
To: dev@hbase.apache.org; lars hofhansl <lh...@yahoo.com>
Sent: Wednesday, January 18, 2012 7:22 PM
Subject: Re: Limited cross row transactions
I find all of these ideas interesting but a little bit scope-creepy.
It used to be that regions were an implementation detail, but with
these new APIs it'd be very much an application-level construct. We
should think carefully before adding new APIs to do this - perhaps we
can start playing with the idea on a branch and see if there are some
really compelling applications?
-Todd
On Wed, Jan 18, 2012 at 7:03 PM, lars hofhansl <lh...@yahoo.com> wrote:
> Was thinking about that as well. That would be doable.
>
> Would still need to be some sort of distributed transaction (in the sense there would be a prepare/vote and commit
> phase between the participating regions),but it would all be local to a single server.
>
>
>
> ________________________________
> From: Ted Yu <yu...@gmail.com>
> To: dev@hbase.apache.org; lars hofhansl <lh...@yahoo.com>
> Sent: Wednesday, January 18, 2012 6:51 PM
> Subject: Re: Limited cross row transactions
>
> Still need to go over the patch, Lars.
>
> I wonder how difficult supporting cross-region transactions in the same
> region server would be.
>
> Cheers
>
> On Wed, Jan 18, 2012 at 5:02 PM, lars hofhansl <lh...@yahoo.com> wrote:
>
>> Filed https://issues.apache.org/jira/browse/HBASE-5229 for further
>> discussion, attached a patch that does this.
>>
>>
>> As for your point...
>> The below is one way to define limited groups of rows that can participate
>> in transactions (I should not have named it parent/child, that just
>> confuses my point).
>> Your scenario calls for global transaction (unless you have to some other
>> approach to limit the scope of rows that could participate in your FK
>> transactions to something less than the entire database).
>>
>> If every transaction is a global transaction the database will not scale.
>>
>> See http://www.julianbrowne.com/article/viewer/brewers-cap-theorem
>> and
>> http://www.cloudera.com/blog/2010/04/cap-confusion-problems-with-partition-tolerance/
>>
>> Also check out two phase commit failure and blocking scenarios, and Paxos'
>> conditions for termination.
>>
>> -- Lars
>>
>>
>> ----- Original Message -----
>> From: Mikael Sitruk <mi...@gmail.com>
>> To: dev@hbase.apache.org; lars hofhansl <lh...@yahoo.com>
>> Cc:
>> Sent: Wednesday, January 18, 2012 12:01 AM
>> Subject: Re: Limited cross row transactions
>>
>> This is for parent child relationship, but what if there is no parent child
>> relationship, but more a foreign key like relationship?
>> Using this model you do a full scan to get all the index (since you don't
>> know the parent, you just know the "secondary index").
>> Or will you use a group ID as a prefix of parent key and "child" key? In
>> this case splitting according to group may be more difficult, (due to
>> different growth of groups).
>> Doing this aren't we back in the headache of sharding in rdbms?
>>
>> Mikael.S
>>
>>
>> On Wed, Jan 18, 2012 at 7:45 AM, lars hofhansl <lh...@yahoo.com>
>> wrote:
>>
>> > This thread is probably getting too long...
>> >
>> > In HBase we have to let go of "global stuff". I submit that global
>> > transactions across 1000's of nodes that can fail will never work
>> > adequately.
>> > For that kind of consistency you will be hit in availability.
>> >
>> > Like Megastore the trick is in creating a local grouping of entities that
>> > can participate in local transactions.
>> > If you limit the (consistent) index to child entities of parent entity
>> you
>> > can form your index like this:
>> > parentKey1...
>> > parentKey1.childTableName1.indexedField1
>> > parentKey1.childTableName1.indexedField2
>> > ...
>> > parentKey1.childTableName2.indexedField1
>> > parentKey1.childTableName2.indexedField2
>> > ...
>> > (assuming . cannot be in any parent key or child table name here, but you
>> > get the idea).
>> >
>> >
>> > When scanning the parent you'd have to skip the index rows with a filter.
>> > Within a parentKey you can find childKeys efficiently by scanning the
>> > index rows.
>> >
>> > Since the parent and the index entries would sort together the table can
>> > be pre-split (or one could have a simple prefix based balancer).
>> >
>> > -- Lars
>> >
>> > ----- Original Message -----
>> > From: Mikael Sitruk <mi...@gmail.com>
>> > To: dev@hbase.apache.org
>> > Cc:
>> > Sent: Tuesday, January 17, 2012 3:07 PM
>> > Subject: Re: Limited cross row transactions
>> >
>> > Well i understand the limitation now, asking to be in the same region is
>> > really hard constraint.
>> > Even if this is on the same RS this is not enough, because after a
>> restart,
>> > regions may be allocated differently and now part of the data may be in
>> one
>> > region under server A and the other part under server B.
>> >
>> > Well perhaps we need use case for better understanding, and perhaps
>> finding
>> > alternative.
>> >
>> > The first use case i was thinking of is as follow -
>> > I need to insert data with different access criteria, but the data
>> inserted
>> > should be inserted in atomic way.
>> > In RDBMS i would have two table, insert data in the first one with key#1
>> > and then in the second one with key #2 then commit.
>> > In HBase i need to use different column family with key #1 (for
>> atomicity)
>> > then to manage a kind of secondary index to map key#2 to key #1 (perhaps
>> > via co-processor) to have quick access to the data of key#2.
>> > Having cross row trx, i would think of sing different keys under the same
>> > table (and probably different cf too), without the need to have secondary
>> > index, but again with the limitation it does not seems to be easily
>> > feasible.
>> >
>> > Mik.
>> >
>> > On Wed, Jan 18, 2012 at 12:22 AM, Ted Yu <yu...@gmail.com> wrote:
>> >
>> > > 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 <yu...@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 <yu...@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
>> > > >
>> > >
>> >
>> >
>> >
>> > --
>> > Mikael.S
>> >
>> >
>>
>>
>> --
>> Mikael.S
>>
>>
--
Todd Lipcon
Software Engineer, Cloudera
Re: Limited cross row transactions
Posted by Todd Lipcon <to...@cloudera.com>.
I find all of these ideas interesting but a little bit scope-creepy.
It used to be that regions were an implementation detail, but with
these new APIs it'd be very much an application-level construct. We
should think carefully before adding new APIs to do this - perhaps we
can start playing with the idea on a branch and see if there are some
really compelling applications?
-Todd
On Wed, Jan 18, 2012 at 7:03 PM, lars hofhansl <lh...@yahoo.com> wrote:
> Was thinking about that as well. That would be doable.
>
> Would still need to be some sort of distributed transaction (in the sense there would be a prepare/vote and commit
> phase between the participating regions),but it would all be local to a single server.
>
>
>
> ________________________________
> From: Ted Yu <yu...@gmail.com>
> To: dev@hbase.apache.org; lars hofhansl <lh...@yahoo.com>
> Sent: Wednesday, January 18, 2012 6:51 PM
> Subject: Re: Limited cross row transactions
>
> Still need to go over the patch, Lars.
>
> I wonder how difficult supporting cross-region transactions in the same
> region server would be.
>
> Cheers
>
> On Wed, Jan 18, 2012 at 5:02 PM, lars hofhansl <lh...@yahoo.com> wrote:
>
>> Filed https://issues.apache.org/jira/browse/HBASE-5229 for further
>> discussion, attached a patch that does this.
>>
>>
>> As for your point...
>> The below is one way to define limited groups of rows that can participate
>> in transactions (I should not have named it parent/child, that just
>> confuses my point).
>> Your scenario calls for global transaction (unless you have to some other
>> approach to limit the scope of rows that could participate in your FK
>> transactions to something less than the entire database).
>>
>> If every transaction is a global transaction the database will not scale.
>>
>> See http://www.julianbrowne.com/article/viewer/brewers-cap-theorem
>> and
>> http://www.cloudera.com/blog/2010/04/cap-confusion-problems-with-partition-tolerance/
>>
>> Also check out two phase commit failure and blocking scenarios, and Paxos'
>> conditions for termination.
>>
>> -- Lars
>>
>>
>> ----- Original Message -----
>> From: Mikael Sitruk <mi...@gmail.com>
>> To: dev@hbase.apache.org; lars hofhansl <lh...@yahoo.com>
>> Cc:
>> Sent: Wednesday, January 18, 2012 12:01 AM
>> Subject: Re: Limited cross row transactions
>>
>> This is for parent child relationship, but what if there is no parent child
>> relationship, but more a foreign key like relationship?
>> Using this model you do a full scan to get all the index (since you don't
>> know the parent, you just know the "secondary index").
>> Or will you use a group ID as a prefix of parent key and "child" key? In
>> this case splitting according to group may be more difficult, (due to
>> different growth of groups).
>> Doing this aren't we back in the headache of sharding in rdbms?
>>
>> Mikael.S
>>
>>
>> On Wed, Jan 18, 2012 at 7:45 AM, lars hofhansl <lh...@yahoo.com>
>> wrote:
>>
>> > This thread is probably getting too long...
>> >
>> > In HBase we have to let go of "global stuff". I submit that global
>> > transactions across 1000's of nodes that can fail will never work
>> > adequately.
>> > For that kind of consistency you will be hit in availability.
>> >
>> > Like Megastore the trick is in creating a local grouping of entities that
>> > can participate in local transactions.
>> > If you limit the (consistent) index to child entities of parent entity
>> you
>> > can form your index like this:
>> > parentKey1...
>> > parentKey1.childTableName1.indexedField1
>> > parentKey1.childTableName1.indexedField2
>> > ...
>> > parentKey1.childTableName2.indexedField1
>> > parentKey1.childTableName2.indexedField2
>> > ...
>> > (assuming . cannot be in any parent key or child table name here, but you
>> > get the idea).
>> >
>> >
>> > When scanning the parent you'd have to skip the index rows with a filter.
>> > Within a parentKey you can find childKeys efficiently by scanning the
>> > index rows.
>> >
>> > Since the parent and the index entries would sort together the table can
>> > be pre-split (or one could have a simple prefix based balancer).
>> >
>> > -- Lars
>> >
>> > ----- Original Message -----
>> > From: Mikael Sitruk <mi...@gmail.com>
>> > To: dev@hbase.apache.org
>> > Cc:
>> > Sent: Tuesday, January 17, 2012 3:07 PM
>> > Subject: Re: Limited cross row transactions
>> >
>> > Well i understand the limitation now, asking to be in the same region is
>> > really hard constraint.
>> > Even if this is on the same RS this is not enough, because after a
>> restart,
>> > regions may be allocated differently and now part of the data may be in
>> one
>> > region under server A and the other part under server B.
>> >
>> > Well perhaps we need use case for better understanding, and perhaps
>> finding
>> > alternative.
>> >
>> > The first use case i was thinking of is as follow -
>> > I need to insert data with different access criteria, but the data
>> inserted
>> > should be inserted in atomic way.
>> > In RDBMS i would have two table, insert data in the first one with key#1
>> > and then in the second one with key #2 then commit.
>> > In HBase i need to use different column family with key #1 (for
>> atomicity)
>> > then to manage a kind of secondary index to map key#2 to key #1 (perhaps
>> > via co-processor) to have quick access to the data of key#2.
>> > Having cross row trx, i would think of sing different keys under the same
>> > table (and probably different cf too), without the need to have secondary
>> > index, but again with the limitation it does not seems to be easily
>> > feasible.
>> >
>> > Mik.
>> >
>> > On Wed, Jan 18, 2012 at 12:22 AM, Ted Yu <yu...@gmail.com> wrote:
>> >
>> > > 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 <yu...@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 <yu...@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
>> > > >
>> > >
>> >
>> >
>> >
>> > --
>> > Mikael.S
>> >
>> >
>>
>>
>> --
>> Mikael.S
>>
>>
--
Todd Lipcon
Software Engineer, Cloudera
Re: Limited cross row transactions
Posted by Ted Yu <yu...@gmail.com>.
One interesting factor is how load balancer can keep the regions from one
region server S1 together in case S1 goes down.
I assume all regions from S1 should be moved onto a single region server S2
- otherwise how do we know that related data are still served by the same
server ?
I think the above cannot easily be accommodated under the original sense of
load balancing.
As Todd said in his response, we should carefully consider the implications
of new functionality before putting the idea down in code.
Sorry for the diversion of the discussion.
On Wed, Jan 18, 2012 at 7:03 PM, lars hofhansl <lh...@yahoo.com> wrote:
> Was thinking about that as well. That would be doable.
>
> Would still need to be some sort of distributed transaction (in the sense
> there would be a prepare/vote and commit
> phase between the participating regions),but it would all be local to a
> single server.
>
>
>
> ________________________________
> From: Ted Yu <yu...@gmail.com>
> To: dev@hbase.apache.org; lars hofhansl <lh...@yahoo.com>
> Sent: Wednesday, January 18, 2012 6:51 PM
> Subject: Re: Limited cross row transactions
>
> Still need to go over the patch, Lars.
>
> I wonder how difficult supporting cross-region transactions in the same
> region server would be.
>
> Cheers
>
> On Wed, Jan 18, 2012 at 5:02 PM, lars hofhansl <lh...@yahoo.com>
> wrote:
>
> > Filed https://issues.apache.org/jira/browse/HBASE-5229 for further
> > discussion, attached a patch that does this.
> >
> >
> > As for your point...
> > The below is one way to define limited groups of rows that can
> participate
> > in transactions (I should not have named it parent/child, that just
> > confuses my point).
> > Your scenario calls for global transaction (unless you have to some other
> > approach to limit the scope of rows that could participate in your FK
> > transactions to something less than the entire database).
> >
> > If every transaction is a global transaction the database will not scale.
> >
> > See http://www.julianbrowne.com/article/viewer/brewers-cap-theorem
> > and
> >
> http://www.cloudera.com/blog/2010/04/cap-confusion-problems-with-partition-tolerance/
> >
> > Also check out two phase commit failure and blocking scenarios, and
> Paxos'
> > conditions for termination.
> >
> > -- Lars
> >
> >
> > ----- Original Message -----
> > From: Mikael Sitruk <mi...@gmail.com>
> > To: dev@hbase.apache.org; lars hofhansl <lh...@yahoo.com>
> > Cc:
> > Sent: Wednesday, January 18, 2012 12:01 AM
> > Subject: Re: Limited cross row transactions
> >
> > This is for parent child relationship, but what if there is no parent
> child
> > relationship, but more a foreign key like relationship?
> > Using this model you do a full scan to get all the index (since you don't
> > know the parent, you just know the "secondary index").
> > Or will you use a group ID as a prefix of parent key and "child" key? In
> > this case splitting according to group may be more difficult, (due to
> > different growth of groups).
> > Doing this aren't we back in the headache of sharding in rdbms?
> >
> > Mikael.S
> >
> >
> > On Wed, Jan 18, 2012 at 7:45 AM, lars hofhansl <lh...@yahoo.com>
> > wrote:
> >
> > > This thread is probably getting too long...
> > >
> > > In HBase we have to let go of "global stuff". I submit that global
> > > transactions across 1000's of nodes that can fail will never work
> > > adequately.
> > > For that kind of consistency you will be hit in availability.
> > >
> > > Like Megastore the trick is in creating a local grouping of entities
> that
> > > can participate in local transactions.
> > > If you limit the (consistent) index to child entities of parent entity
> > you
> > > can form your index like this:
> > > parentKey1...
> > > parentKey1.childTableName1.indexedField1
> > > parentKey1.childTableName1.indexedField2
> > > ...
> > > parentKey1.childTableName2.indexedField1
> > > parentKey1.childTableName2.indexedField2
> > > ...
> > > (assuming . cannot be in any parent key or child table name here, but
> you
> > > get the idea).
> > >
> > >
> > > When scanning the parent you'd have to skip the index rows with a
> filter.
> > > Within a parentKey you can find childKeys efficiently by scanning the
> > > index rows.
> > >
> > > Since the parent and the index entries would sort together the table
> can
> > > be pre-split (or one could have a simple prefix based balancer).
> > >
> > > -- Lars
> > >
> > > ----- Original Message -----
> > > From: Mikael Sitruk <mi...@gmail.com>
> > > To: dev@hbase.apache.org
> > > Cc:
> > > Sent: Tuesday, January 17, 2012 3:07 PM
> > > Subject: Re: Limited cross row transactions
> > >
> > > Well i understand the limitation now, asking to be in the same region
> is
> > > really hard constraint.
> > > Even if this is on the same RS this is not enough, because after a
> > restart,
> > > regions may be allocated differently and now part of the data may be in
> > one
> > > region under server A and the other part under server B.
> > >
> > > Well perhaps we need use case for better understanding, and perhaps
> > finding
> > > alternative.
> > >
> > > The first use case i was thinking of is as follow -
> > > I need to insert data with different access criteria, but the data
> > inserted
> > > should be inserted in atomic way.
> > > In RDBMS i would have two table, insert data in the first one with
> key#1
> > > and then in the second one with key #2 then commit.
> > > In HBase i need to use different column family with key #1 (for
> > atomicity)
> > > then to manage a kind of secondary index to map key#2 to key #1
> (perhaps
> > > via co-processor) to have quick access to the data of key#2.
> > > Having cross row trx, i would think of sing different keys under the
> same
> > > table (and probably different cf too), without the need to have
> secondary
> > > index, but again with the limitation it does not seems to be easily
> > > feasible.
> > >
> > > Mik.
> > >
> > > On Wed, Jan 18, 2012 at 12:22 AM, Ted Yu <yu...@gmail.com> wrote:
> > >
> > > > 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 <yu...@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 <yu...@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
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Mikael.S
> > >
> > >
> >
> >
> > --
> > Mikael.S
> >
> >
>
Re: Limited cross row transactions
Posted by lars hofhansl <lh...@yahoo.com>.
Was thinking about that as well. That would be doable.
Would still need to be some sort of distributed transaction (in the sense there would be a prepare/vote and commit
phase between the participating regions),but it would all be local to a single server.
________________________________
From: Ted Yu <yu...@gmail.com>
To: dev@hbase.apache.org; lars hofhansl <lh...@yahoo.com>
Sent: Wednesday, January 18, 2012 6:51 PM
Subject: Re: Limited cross row transactions
Still need to go over the patch, Lars.
I wonder how difficult supporting cross-region transactions in the same
region server would be.
Cheers
On Wed, Jan 18, 2012 at 5:02 PM, lars hofhansl <lh...@yahoo.com> wrote:
> Filed https://issues.apache.org/jira/browse/HBASE-5229 for further
> discussion, attached a patch that does this.
>
>
> As for your point...
> The below is one way to define limited groups of rows that can participate
> in transactions (I should not have named it parent/child, that just
> confuses my point).
> Your scenario calls for global transaction (unless you have to some other
> approach to limit the scope of rows that could participate in your FK
> transactions to something less than the entire database).
>
> If every transaction is a global transaction the database will not scale.
>
> See http://www.julianbrowne.com/article/viewer/brewers-cap-theorem
> and
> http://www.cloudera.com/blog/2010/04/cap-confusion-problems-with-partition-tolerance/
>
> Also check out two phase commit failure and blocking scenarios, and Paxos'
> conditions for termination.
>
> -- Lars
>
>
> ----- Original Message -----
> From: Mikael Sitruk <mi...@gmail.com>
> To: dev@hbase.apache.org; lars hofhansl <lh...@yahoo.com>
> Cc:
> Sent: Wednesday, January 18, 2012 12:01 AM
> Subject: Re: Limited cross row transactions
>
> This is for parent child relationship, but what if there is no parent child
> relationship, but more a foreign key like relationship?
> Using this model you do a full scan to get all the index (since you don't
> know the parent, you just know the "secondary index").
> Or will you use a group ID as a prefix of parent key and "child" key? In
> this case splitting according to group may be more difficult, (due to
> different growth of groups).
> Doing this aren't we back in the headache of sharding in rdbms?
>
> Mikael.S
>
>
> On Wed, Jan 18, 2012 at 7:45 AM, lars hofhansl <lh...@yahoo.com>
> wrote:
>
> > This thread is probably getting too long...
> >
> > In HBase we have to let go of "global stuff". I submit that global
> > transactions across 1000's of nodes that can fail will never work
> > adequately.
> > For that kind of consistency you will be hit in availability.
> >
> > Like Megastore the trick is in creating a local grouping of entities that
> > can participate in local transactions.
> > If you limit the (consistent) index to child entities of parent entity
> you
> > can form your index like this:
> > parentKey1...
> > parentKey1.childTableName1.indexedField1
> > parentKey1.childTableName1.indexedField2
> > ...
> > parentKey1.childTableName2.indexedField1
> > parentKey1.childTableName2.indexedField2
> > ...
> > (assuming . cannot be in any parent key or child table name here, but you
> > get the idea).
> >
> >
> > When scanning the parent you'd have to skip the index rows with a filter.
> > Within a parentKey you can find childKeys efficiently by scanning the
> > index rows.
> >
> > Since the parent and the index entries would sort together the table can
> > be pre-split (or one could have a simple prefix based balancer).
> >
> > -- Lars
> >
> > ----- Original Message -----
> > From: Mikael Sitruk <mi...@gmail.com>
> > To: dev@hbase.apache.org
> > Cc:
> > Sent: Tuesday, January 17, 2012 3:07 PM
> > Subject: Re: Limited cross row transactions
> >
> > Well i understand the limitation now, asking to be in the same region is
> > really hard constraint.
> > Even if this is on the same RS this is not enough, because after a
> restart,
> > regions may be allocated differently and now part of the data may be in
> one
> > region under server A and the other part under server B.
> >
> > Well perhaps we need use case for better understanding, and perhaps
> finding
> > alternative.
> >
> > The first use case i was thinking of is as follow -
> > I need to insert data with different access criteria, but the data
> inserted
> > should be inserted in atomic way.
> > In RDBMS i would have two table, insert data in the first one with key#1
> > and then in the second one with key #2 then commit.
> > In HBase i need to use different column family with key #1 (for
> atomicity)
> > then to manage a kind of secondary index to map key#2 to key #1 (perhaps
> > via co-processor) to have quick access to the data of key#2.
> > Having cross row trx, i would think of sing different keys under the same
> > table (and probably different cf too), without the need to have secondary
> > index, but again with the limitation it does not seems to be easily
> > feasible.
> >
> > Mik.
> >
> > On Wed, Jan 18, 2012 at 12:22 AM, Ted Yu <yu...@gmail.com> wrote:
> >
> > > 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 <yu...@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 <yu...@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
> > > >
> > >
> >
> >
> >
> > --
> > Mikael.S
> >
> >
>
>
> --
> Mikael.S
>
>
Re: Limited cross row transactions
Posted by Ted Yu <yu...@gmail.com>.
Still need to go over the patch, Lars.
I wonder how difficult supporting cross-region transactions in the same
region server would be.
Cheers
On Wed, Jan 18, 2012 at 5:02 PM, lars hofhansl <lh...@yahoo.com> wrote:
> Filed https://issues.apache.org/jira/browse/HBASE-5229 for further
> discussion, attached a patch that does this.
>
>
> As for your point...
> The below is one way to define limited groups of rows that can participate
> in transactions (I should not have named it parent/child, that just
> confuses my point).
> Your scenario calls for global transaction (unless you have to some other
> approach to limit the scope of rows that could participate in your FK
> transactions to something less than the entire database).
>
> If every transaction is a global transaction the database will not scale.
>
> See http://www.julianbrowne.com/article/viewer/brewers-cap-theorem
> and
> http://www.cloudera.com/blog/2010/04/cap-confusion-problems-with-partition-tolerance/
>
> Also check out two phase commit failure and blocking scenarios, and Paxos'
> conditions for termination.
>
> -- Lars
>
>
> ----- Original Message -----
> From: Mikael Sitruk <mi...@gmail.com>
> To: dev@hbase.apache.org; lars hofhansl <lh...@yahoo.com>
> Cc:
> Sent: Wednesday, January 18, 2012 12:01 AM
> Subject: Re: Limited cross row transactions
>
> This is for parent child relationship, but what if there is no parent child
> relationship, but more a foreign key like relationship?
> Using this model you do a full scan to get all the index (since you don't
> know the parent, you just know the "secondary index").
> Or will you use a group ID as a prefix of parent key and "child" key? In
> this case splitting according to group may be more difficult, (due to
> different growth of groups).
> Doing this aren't we back in the headache of sharding in rdbms?
>
> Mikael.S
>
>
> On Wed, Jan 18, 2012 at 7:45 AM, lars hofhansl <lh...@yahoo.com>
> wrote:
>
> > This thread is probably getting too long...
> >
> > In HBase we have to let go of "global stuff". I submit that global
> > transactions across 1000's of nodes that can fail will never work
> > adequately.
> > For that kind of consistency you will be hit in availability.
> >
> > Like Megastore the trick is in creating a local grouping of entities that
> > can participate in local transactions.
> > If you limit the (consistent) index to child entities of parent entity
> you
> > can form your index like this:
> > parentKey1...
> > parentKey1.childTableName1.indexedField1
> > parentKey1.childTableName1.indexedField2
> > ...
> > parentKey1.childTableName2.indexedField1
> > parentKey1.childTableName2.indexedField2
> > ...
> > (assuming . cannot be in any parent key or child table name here, but you
> > get the idea).
> >
> >
> > When scanning the parent you'd have to skip the index rows with a filter.
> > Within a parentKey you can find childKeys efficiently by scanning the
> > index rows.
> >
> > Since the parent and the index entries would sort together the table can
> > be pre-split (or one could have a simple prefix based balancer).
> >
> > -- Lars
> >
> > ----- Original Message -----
> > From: Mikael Sitruk <mi...@gmail.com>
> > To: dev@hbase.apache.org
> > Cc:
> > Sent: Tuesday, January 17, 2012 3:07 PM
> > Subject: Re: Limited cross row transactions
> >
> > Well i understand the limitation now, asking to be in the same region is
> > really hard constraint.
> > Even if this is on the same RS this is not enough, because after a
> restart,
> > regions may be allocated differently and now part of the data may be in
> one
> > region under server A and the other part under server B.
> >
> > Well perhaps we need use case for better understanding, and perhaps
> finding
> > alternative.
> >
> > The first use case i was thinking of is as follow -
> > I need to insert data with different access criteria, but the data
> inserted
> > should be inserted in atomic way.
> > In RDBMS i would have two table, insert data in the first one with key#1
> > and then in the second one with key #2 then commit.
> > In HBase i need to use different column family with key #1 (for
> atomicity)
> > then to manage a kind of secondary index to map key#2 to key #1 (perhaps
> > via co-processor) to have quick access to the data of key#2.
> > Having cross row trx, i would think of sing different keys under the same
> > table (and probably different cf too), without the need to have secondary
> > index, but again with the limitation it does not seems to be easily
> > feasible.
> >
> > Mik.
> >
> > On Wed, Jan 18, 2012 at 12:22 AM, Ted Yu <yu...@gmail.com> wrote:
> >
> > > 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 <yu...@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 <yu...@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
> > > >
> > >
> >
> >
> >
> > --
> > Mikael.S
> >
> >
>
>
> --
> Mikael.S
>
>
Re: Limited cross row transactions
Posted by lars hofhansl <lh...@yahoo.com>.
Filed https://issues.apache.org/jira/browse/HBASE-5229 for further discussion, attached a patch that does this.
As for your point...
The below is one way to define limited groups of rows that can participate in transactions (I should not have named it parent/child, that just confuses my point).
Your scenario calls for global transaction (unless you have to some other approach to limit the scope of rows that could participate in your FK transactions to something less than the entire database).
If every transaction is a global transaction the database will not scale.
See http://www.julianbrowne.com/article/viewer/brewers-cap-theorem
and http://www.cloudera.com/blog/2010/04/cap-confusion-problems-with-partition-tolerance/
Also check out two phase commit failure and blocking scenarios, and Paxos' conditions for termination.
-- Lars
----- Original Message -----
From: Mikael Sitruk <mi...@gmail.com>
To: dev@hbase.apache.org; lars hofhansl <lh...@yahoo.com>
Cc:
Sent: Wednesday, January 18, 2012 12:01 AM
Subject: Re: Limited cross row transactions
This is for parent child relationship, but what if there is no parent child
relationship, but more a foreign key like relationship?
Using this model you do a full scan to get all the index (since you don't
know the parent, you just know the "secondary index").
Or will you use a group ID as a prefix of parent key and "child" key? In
this case splitting according to group may be more difficult, (due to
different growth of groups).
Doing this aren't we back in the headache of sharding in rdbms?
Mikael.S
On Wed, Jan 18, 2012 at 7:45 AM, lars hofhansl <lh...@yahoo.com> wrote:
> This thread is probably getting too long...
>
> In HBase we have to let go of "global stuff". I submit that global
> transactions across 1000's of nodes that can fail will never work
> adequately.
> For that kind of consistency you will be hit in availability.
>
> Like Megastore the trick is in creating a local grouping of entities that
> can participate in local transactions.
> If you limit the (consistent) index to child entities of parent entity you
> can form your index like this:
> parentKey1...
> parentKey1.childTableName1.indexedField1
> parentKey1.childTableName1.indexedField2
> ...
> parentKey1.childTableName2.indexedField1
> parentKey1.childTableName2.indexedField2
> ...
> (assuming . cannot be in any parent key or child table name here, but you
> get the idea).
>
>
> When scanning the parent you'd have to skip the index rows with a filter.
> Within a parentKey you can find childKeys efficiently by scanning the
> index rows.
>
> Since the parent and the index entries would sort together the table can
> be pre-split (or one could have a simple prefix based balancer).
>
> -- Lars
>
> ----- Original Message -----
> From: Mikael Sitruk <mi...@gmail.com>
> To: dev@hbase.apache.org
> Cc:
> Sent: Tuesday, January 17, 2012 3:07 PM
> Subject: Re: Limited cross row transactions
>
> Well i understand the limitation now, asking to be in the same region is
> really hard constraint.
> Even if this is on the same RS this is not enough, because after a restart,
> regions may be allocated differently and now part of the data may be in one
> region under server A and the other part under server B.
>
> Well perhaps we need use case for better understanding, and perhaps finding
> alternative.
>
> The first use case i was thinking of is as follow -
> I need to insert data with different access criteria, but the data inserted
> should be inserted in atomic way.
> In RDBMS i would have two table, insert data in the first one with key#1
> and then in the second one with key #2 then commit.
> In HBase i need to use different column family with key #1 (for atomicity)
> then to manage a kind of secondary index to map key#2 to key #1 (perhaps
> via co-processor) to have quick access to the data of key#2.
> Having cross row trx, i would think of sing different keys under the same
> table (and probably different cf too), without the need to have secondary
> index, but again with the limitation it does not seems to be easily
> feasible.
>
> Mik.
>
> On Wed, Jan 18, 2012 at 12:22 AM, Ted Yu <yu...@gmail.com> wrote:
>
> > 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 <yu...@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 <yu...@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
> > >
> >
>
>
>
> --
> Mikael.S
>
>
--
Mikael.S
Re: Limited cross row transactions
Posted by Mikael Sitruk <mi...@gmail.com>.
This is for parent child relationship, but what if there is no parent child
relationship, but more a foreign key like relationship?
Using this model you do a full scan to get all the index (since you don't
know the parent, you just know the "secondary index").
Or will you use a group ID as a prefix of parent key and "child" key? In
this case splitting according to group may be more difficult, (due to
different growth of groups).
Doing this aren't we back in the headache of sharding in rdbms?
Mikael.S
On Wed, Jan 18, 2012 at 7:45 AM, lars hofhansl <lh...@yahoo.com> wrote:
> This thread is probably getting too long...
>
> In HBase we have to let go of "global stuff". I submit that global
> transactions across 1000's of nodes that can fail will never work
> adequately.
> For that kind of consistency you will be hit in availability.
>
> Like Megastore the trick is in creating a local grouping of entities that
> can participate in local transactions.
> If you limit the (consistent) index to child entities of parent entity you
> can form your index like this:
> parentKey1...
> parentKey1.childTableName1.indexedField1
> parentKey1.childTableName1.indexedField2
> ...
> parentKey1.childTableName2.indexedField1
> parentKey1.childTableName2.indexedField2
> ...
> (assuming . cannot be in any parent key or child table name here, but you
> get the idea).
>
>
> When scanning the parent you'd have to skip the index rows with a filter.
> Within a parentKey you can find childKeys efficiently by scanning the
> index rows.
>
> Since the parent and the index entries would sort together the table can
> be pre-split (or one could have a simple prefix based balancer).
>
> -- Lars
>
> ----- Original Message -----
> From: Mikael Sitruk <mi...@gmail.com>
> To: dev@hbase.apache.org
> Cc:
> Sent: Tuesday, January 17, 2012 3:07 PM
> Subject: Re: Limited cross row transactions
>
> Well i understand the limitation now, asking to be in the same region is
> really hard constraint.
> Even if this is on the same RS this is not enough, because after a restart,
> regions may be allocated differently and now part of the data may be in one
> region under server A and the other part under server B.
>
> Well perhaps we need use case for better understanding, and perhaps finding
> alternative.
>
> The first use case i was thinking of is as follow -
> I need to insert data with different access criteria, but the data inserted
> should be inserted in atomic way.
> In RDBMS i would have two table, insert data in the first one with key#1
> and then in the second one with key #2 then commit.
> In HBase i need to use different column family with key #1 (for atomicity)
> then to manage a kind of secondary index to map key#2 to key #1 (perhaps
> via co-processor) to have quick access to the data of key#2.
> Having cross row trx, i would think of sing different keys under the same
> table (and probably different cf too), without the need to have secondary
> index, but again with the limitation it does not seems to be easily
> feasible.
>
> Mik.
>
> On Wed, Jan 18, 2012 at 12:22 AM, Ted Yu <yu...@gmail.com> wrote:
>
> > 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 <yu...@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 <yu...@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
> > >
> >
>
>
>
> --
> Mikael.S
>
>
--
Mikael.S
Re: Limited cross row transactions
Posted by lars hofhansl <lh...@yahoo.com>.
This thread is probably getting too long...
In HBase we have to let go of "global stuff". I submit that global transactions across 1000's of nodes that can fail will never work adequately.
For that kind of consistency you will be hit in availability.
Like Megastore the trick is in creating a local grouping of entities that can participate in local transactions.
If you limit the (consistent) index to child entities of parent entity you can form your index like this:
parentKey1...
parentKey1.childTableName1.indexedField1
parentKey1.childTableName1.indexedField2
...
parentKey1.childTableName2.indexedField1
parentKey1.childTableName2.indexedField2
...
(assuming . cannot be in any parent key or child table name here, but you get the idea).
When scanning the parent you'd have to skip the index rows with a filter.
Within a parentKey you can find childKeys efficiently by scanning the index rows.
Since the parent and the index entries would sort together the table can be pre-split (or one could have a simple prefix based balancer).
-- Lars
----- Original Message -----
From: Mikael Sitruk <mi...@gmail.com>
To: dev@hbase.apache.org
Cc:
Sent: Tuesday, January 17, 2012 3:07 PM
Subject: Re: Limited cross row transactions
Well i understand the limitation now, asking to be in the same region is
really hard constraint.
Even if this is on the same RS this is not enough, because after a restart,
regions may be allocated differently and now part of the data may be in one
region under server A and the other part under server B.
Well perhaps we need use case for better understanding, and perhaps finding
alternative.
The first use case i was thinking of is as follow -
I need to insert data with different access criteria, but the data inserted
should be inserted in atomic way.
In RDBMS i would have two table, insert data in the first one with key#1
and then in the second one with key #2 then commit.
In HBase i need to use different column family with key #1 (for atomicity)
then to manage a kind of secondary index to map key#2 to key #1 (perhaps
via co-processor) to have quick access to the data of key#2.
Having cross row trx, i would think of sing different keys under the same
table (and probably different cf too), without the need to have secondary
index, but again with the limitation it does not seems to be easily
feasible.
Mik.
On Wed, Jan 18, 2012 at 12:22 AM, Ted Yu <yu...@gmail.com> wrote:
> 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 <yu...@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 <yu...@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
> >
>
--
Mikael.S
Re: Limited cross row transactions
Posted by Mikael Sitruk <mi...@gmail.com>.
Well i understand the limitation now, asking to be in the same region is
really hard constraint.
Even if this is on the same RS this is not enough, because after a restart,
regions may be allocated differently and now part of the data may be in one
region under server A and the other part under server B.
Well perhaps we need use case for better understanding, and perhaps finding
alternative.
The first use case i was thinking of is as follow -
I need to insert data with different access criteria, but the data inserted
should be inserted in atomic way.
In RDBMS i would have two table, insert data in the first one with key#1
and then in the second one with key #2 then commit.
In HBase i need to use different column family with key #1 (for atomicity)
then to manage a kind of secondary index to map key#2 to key #1 (perhaps
via co-processor) to have quick access to the data of key#2.
Having cross row trx, i would think of sing different keys under the same
table (and probably different cf too), without the need to have secondary
index, but again with the limitation it does not seems to be easily
feasible.
Mik.
On Wed, Jan 18, 2012 at 12:22 AM, Ted Yu <yu...@gmail.com> wrote:
> 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 <yu...@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 <yu...@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
> >
>
--
Mikael.S
Re: Limited cross row transactions
Posted by Ted Yu <yu...@gmail.com>.
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 <mi...@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 <yu...@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 <yu...@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
>
Re: Limited cross row transactions
Posted by Mikael Sitruk <mi...@gmail.com>.
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 <yu...@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 <yu...@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 <lh...@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
Re: Limited cross row transactions
Posted by lars hofhansl <lh...@yahoo.com>.
Oh... It's up to the client code to make this work.
This comes back to me just providing building blocks and not a full transactional API.
----- Original Message -----
From: Ted Yu <yu...@gmail.com>
To: dev@hbase.apache.org
Cc:
Sent: Tuesday, January 17, 2012 1:52 PM
Subject: Re: Limited cross row transactions
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 <yu...@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 <la...@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 <lh...@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
>> >>
>> >>
>>
>>
>
Re: Limited cross row transactions
Posted by Ted Yu <yu...@gmail.com>.
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 <yu...@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 <la...@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 <lh...@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
>> >>
>> >>
>>
>>
>
Re: Limited cross row transactions
Posted by Ted Yu <yu...@gmail.com>.
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 <la...@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 <lh...@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
> >>
> >>
>
>
Re: Limited cross row transactions
Posted by Lars George <la...@gmail.com>.
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 <lh...@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
>>
>>
Re: Limited cross row transactions
Posted by lars hofhansl <lh...@yahoo.com>.
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 <yu...@gmail.com>
To: dev@hbase.apache.org; lars hofhansl <lh...@yahoo.com>
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 <lh...@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
>
>
Re: Limited cross row transactions
Posted by Ted Yu <yu...@gmail.com>.
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 <lh...@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
>
>