FAQ

[HBase-dev] Limited cross row transactions

Lars hofhansl
Jan 17, 2012 at 9:27 pm
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
reply

Search Discussions

30 responses

  • Lars George at Jan 17, 2012 at 9:32 pm
    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 Sitruk at Jan 17, 2012 at 9:49 pm
    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 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
  • Jesse Yates at Jan 17, 2012 at 9:33 pm
    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 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
  • Ted Yu at Jan 17, 2012 at 9:36 pm
    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 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
  • Lars George at Jan 17, 2012 at 9:42 pm
    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 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
  • Ted Yu at Jan 17, 2012 at 9:50 pm
    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 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 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
  • Ted Yu at Jan 17, 2012 at 9:53 pm
    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 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 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 Sitruk at Jan 17, 2012 at 10:13 pm
    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 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 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
  • Ted Yu at Jan 17, 2012 at 10:23 pm
    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 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 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 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 Sitruk at Jan 17, 2012 at 11:08 pm
    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 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 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 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
  • Lars hofhansl at Jan 18, 2012 at 12:49 am
    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 <mikael.sitruk@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 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 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 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
  • Ted Yu at Jan 18, 2012 at 12:57 am
    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 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 <mikael.sitruk@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 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 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 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
  • Matt Corgan at Jan 18, 2012 at 1:16 am

    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 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 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 <mikael.sitruk@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 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 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 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
  • Lars hofhansl at Jan 18, 2012 at 5:17 am
    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 <mcorgan@hotpads.com>
    To: dev@hbase.apache.org
    Cc: lars hofhansl <lhofhansl@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 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 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 <mikael.sitruk@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 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 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 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
  • Lars hofhansl at Jan 18, 2012 at 1:52 am
    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 <yuzhihong@gmail.com>
    To: dev@hbase.apache.org; lars hofhansl <lhofhansl@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 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 <mikael.sitruk@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 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 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 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
  • Lars hofhansl at Jan 18, 2012 at 5:46 am
    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 <mikael.sitruk@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 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 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 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 Sitruk at Jan 18, 2012 at 8:02 am
    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 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 <mikael.sitruk@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 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 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 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
  • Lars hofhansl at Jan 19, 2012 at 1:02 am
    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 <mikael.sitruk@gmail.com>
    To: dev@hbase.apache.org; lars hofhansl <lhofhansl@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 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 <mikael.sitruk@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 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 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 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
  • Ted Yu at Jan 19, 2012 at 2:52 am
    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 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 <mikael.sitruk@gmail.com>
    To: dev@hbase.apache.org; lars hofhansl <lhofhansl@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 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 <mikael.sitruk@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 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 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 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
  • Lars hofhansl at Jan 19, 2012 at 3:04 am
    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 <yuzhihong@gmail.com>
    To: dev@hbase.apache.org; lars hofhansl <lhofhansl@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 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 <mikael.sitruk@gmail.com>
    To: dev@hbase.apache.org; lars hofhansl <lhofhansl@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 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 <mikael.sitruk@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 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 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 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 at Jan 19, 2012 at 3:23 am
    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 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 <yuzhihong@gmail.com>
    To: dev@hbase.apache.org; lars hofhansl <lhofhansl@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 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 <mikael.sitruk@gmail.com>
    To: dev@hbase.apache.org; lars hofhansl <lhofhansl@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 <lhofhansl@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 <mikael.sitruk@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 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 <yuzhihong@gmail.com>
    wrote:
    Back to original proposal:
    If client side grouping reveals that the batch of operations cannot
    be
    supported by 'limited cross row transactions', what should the user
    do
    ?
    Cheers

    On Tue, Jan 17, 2012 at 1:49 PM, Ted Yu <yuzhihong@gmail.com>
    wrote:
    Whether Omid fits the bill is open to discussion.

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


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

    Wouldn't Omid (https://github.com/yahoo/omid) help there? Or is
    that
    too
    broad? Just curious.

    Lars
    On Jan 17, 2012, at 4:36 PM, Ted Yu wrote:

    Can we collect use case for 'limited cross row transactions'
    first ?
    I have been thinking about (unlimited) multi-row transaction
    support
    in
    HBase. It may not be a one-man task. But we should definitely
    implement
    it
    someday.

    Cheers

    On Tue, Jan 17, 2012 at 1:27 PM, lars hofhansl <
    lhofhansl@yahoo.com
    wrote:
    I just committed HBASE-5203 (together with HBASE-3584 this
    implements
    atomic row operations).
    Although a relatively small patch it lays the groundwork for
    heterogeneous
    operations in a single WALEdit.

    The interesting part is that even though the code enforced
    the
    atomic
    operation to be a for single row, this is not required.
    It is enough if all involved KVs reside in the same region.

    I am not saying that we should add any high level concept to
    HBase
    (such
    as the EntityGroups of Megastore).

    But, with a slight addition to the API (allowing a grouping
    of
    multiple
    row operations) client applications have all the building
    blocks
    to
    do
    limited cross row atomic operations.
    The client application would be responsible for either
    correctly
    pre-splitting the table, or a custom balancer has to be
    provided.
    The operation would fail if the regionserver determines that
    it
    would
    need
    data from multiple region servers.

    I think this needs at least minimal support from HBase and
    cannot
    (efficiently or without adding more moving parts) by a client
    API
    only.

    Comments? Is this worth pursuing? If so, I'll file a jira and
    provide a
    patch.

    Thanks.


    -- Lars


    --
    Mikael.S


    --
    Mikael.S

    --
    Mikael.S


    --
    Todd Lipcon
    Software Engineer, Cloudera
  • Lars hofhansl at Jan 19, 2012 at 5:17 am
    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 <todd@cloudera.com>
    To: dev@hbase.apache.org; lars hofhansl <lhofhansl@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 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 <yuzhihong@gmail.com>
    To: dev@hbase.apache.org; lars hofhansl <lhofhansl@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 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 <mikael.sitruk@gmail.com>
    To: dev@hbase.apache.org; lars hofhansl <lhofhansl@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 <lhofhansl@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 <mikael.sitruk@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 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 <yuzhihong@gmail.com>
    wrote:
    Back to original proposal:
    If client side grouping reveals that the batch of operations cannot
    be
    supported by 'limited cross row transactions', what should the user
    do
    ?
    Cheers

    On Tue, Jan 17, 2012 at 1:49 PM, Ted Yu <yuzhihong@gmail.com>
    wrote:
    Whether Omid fits the bill is open to discussion.

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


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

    Wouldn't Omid (https://github.com/yahoo/omid) help there? Or is
    that
    too
    broad? Just curious.

    Lars
    On Jan 17, 2012, at 4:36 PM, Ted Yu wrote:

    Can we collect use case for 'limited cross row transactions'
    first ?
    I have been thinking about (unlimited) multi-row transaction
    support
    in
    HBase. It may not be a one-man task. But we should definitely
    implement
    it
    someday.

    Cheers

    On Tue, Jan 17, 2012 at 1:27 PM, lars hofhansl <
    lhofhansl@yahoo.com
    wrote:
    I just committed HBASE-5203 (together with HBASE-3584 this
    implements
    atomic row operations).
    Although a relatively small patch it lays the groundwork for
    heterogeneous
    operations in a single WALEdit.

    The interesting part is that even though the code enforced
    the
    atomic
    operation to be a for single row, this is not required.
    It is enough if all involved KVs reside in the same region.

    I am not saying that we should add any high level concept to
    HBase
    (such
    as the EntityGroups of Megastore).

    But, with a slight addition to the API (allowing a grouping
    of
    multiple
    row operations) client applications have all the building
    blocks
    to
    do
    limited cross row atomic operations.
    The client application would be responsible for either
    correctly
    pre-splitting the table, or a custom balancer has to be
    provided.
    The operation would fail if the regionserver determines that
    it
    would
    need
    data from multiple region servers.

    I think this needs at least minimal support from HBase and
    cannot
    (efficiently or without adding more moving parts) by a client
    API
    only.

    Comments? Is this worth pursuing? If so, I'll file a jira and
    provide a
    patch.

    Thanks.


    -- Lars


    --
    Mikael.S


    --
    Mikael.S

    --
    Mikael.S


    --
    Todd Lipcon
    Software Engineer, Cloudera
  • Ted Yu at Jan 19, 2012 at 3:29 am
    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 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 <yuzhihong@gmail.com>
    To: dev@hbase.apache.org; lars hofhansl <lhofhansl@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 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 <mikael.sitruk@gmail.com>
    To: dev@hbase.apache.org; lars hofhansl <lhofhansl@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 <lhofhansl@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 <mikael.sitruk@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 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 <yuzhihong@gmail.com>
    wrote:
    Back to original proposal:
    If client side grouping reveals that the batch of operations
    cannot
    be
    supported by 'limited cross row transactions', what should the
    user
    do
    ?
    Cheers

    On Tue, Jan 17, 2012 at 1:49 PM, Ted Yu <yuzhihong@gmail.com>
    wrote:
    Whether Omid fits the bill is open to discussion.

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


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

    Wouldn't Omid (https://github.com/yahoo/omid) help there? Or
    is
    that
    too
    broad? Just curious.

    Lars
    On Jan 17, 2012, at 4:36 PM, Ted Yu wrote:

    Can we collect use case for 'limited cross row transactions'
    first ?
    I have been thinking about (unlimited) multi-row transaction
    support
    in
    HBase. It may not be a one-man task. But we should
    definitely
    implement
    it
    someday.

    Cheers

    On Tue, Jan 17, 2012 at 1:27 PM, lars hofhansl <
    lhofhansl@yahoo.com
    wrote:
    I just committed HBASE-5203 (together with HBASE-3584 this
    implements
    atomic row operations).
    Although a relatively small patch it lays the groundwork
    for
    heterogeneous
    operations in a single WALEdit.

    The interesting part is that even though the code enforced
    the
    atomic
    operation to be a for single row, this is not required.
    It is enough if all involved KVs reside in the same region.

    I am not saying that we should add any high level concept
    to
    HBase
    (such
    as the EntityGroups of Megastore).

    But, with a slight addition to the API (allowing a grouping
    of
    multiple
    row operations) client applications have all the building
    blocks
    to
    do
    limited cross row atomic operations.
    The client application would be responsible for either
    correctly
    pre-splitting the table, or a custom balancer has to be
    provided.
    The operation would fail if the regionserver determines
    that
    it
    would
    need
    data from multiple region servers.

    I think this needs at least minimal support from HBase and
    cannot
    (efficiently or without adding more moving parts) by a
    client
    API
    only.

    Comments? Is this worth pursuing? If so, I'll file a jira
    and
    provide a
    patch.

    Thanks.


    -- Lars


    --
    Mikael.S


    --
    Mikael.S

    --
    Mikael.S
  • Lars hofhansl at Feb 11, 2012 at 10:35 pm
    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 <lhofhansl@yahoo.com>
    To: "dev@hbase.apache.org" <dev@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 <mikael.sitruk@gmail.com>
    To: dev@hbase.apache.org; lars hofhansl <lhofhansl@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 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 <mikael.sitruk@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 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 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 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
  • Jesse Yates at Jan 17, 2012 at 10:14 pm
    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 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 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
  • Lars hofhansl at Jan 17, 2012 at 10:55 pm
    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 <yuzhihong@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 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 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
  • Lars hofhansl at Jan 17, 2012 at 10:54 pm
    Hey Ted,

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


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

    -- Lars



    ----- Original Message -----
    From: Ted Yu <yuzhihong@gmail.com>
    To: dev@hbase.apache.org; lars hofhansl <lhofhansl@yahoo.com>
    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 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
  • Stack at Jan 17, 2012 at 10:23 pm

    On Tue, Jan 17, 2012 at 1:27 PM, lars hofhansl 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
  • Lars hofhansl at Jan 17, 2012 at 10:59 pm
    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 <stack@duboce.net>
    To: dev@hbase.apache.org; lars hofhansl <lhofhansl@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 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
  • Lars H at Jan 18, 2012 at 1:38 am
    That would certainly be more powerful and useful!

    Stack <stack@duboce.net> schrieb:
    On Tue, Jan 17, 2012 at 1:27 PM, lars hofhansl 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

Related Discussions