hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lars Hofhansl (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-5229) Explore building blocks for "multi-row" local transactions.
Date Mon, 23 Jan 2012 04:21:40 GMT

    [ https://issues.apache.org/jira/browse/HBASE-5229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13190864#comment-13190864

Lars Hofhansl commented on HBASE-5229:

It turns out that there is no reliable ordering between KeyValues in different families (for
the same row key).
Neither should there be, really, since stores should (in theory - not done, yet) be able to
retrieve KVs in parallel. So starting at (row1, familyX, columnA) and ending at (row1, familyY,
columnB) has no meaning.
Maybe that should have been obvious... See comment in KeyValue.KeyComparator(...):
// TODO the family and qualifier should be compared separately
compare = Bytes.compareTo(left, lcolumnoffset, lcolumnlength, right,
   rcolumnoffset, rcolumnlength);
Not sure if that is separate bug. Indeed a ("row1", "family", "12") is equal to ("row1", "family1",
"2") by this comparator.

After all this, it looks like the best bet is to use the existing ColumnRangeFilter for intra-row
scanning. If only one (or a few) families are used, that will be pretty efficient too, as
ColumnRangeFilter seeks to the appropriate KV.

I'll close this issue.
> Explore building blocks for "multi-row" local transactions.
> -----------------------------------------------------------
>                 Key: HBASE-5229
>                 URL: https://issues.apache.org/jira/browse/HBASE-5229
>             Project: HBase
>          Issue Type: New Feature
>          Components: client, regionserver
>            Reporter: Lars Hofhansl
>            Assignee: Lars Hofhansl
>             Fix For: 0.94.0
>         Attachments: 5229-seekto-v2.txt, 5229-seekto.txt, 5229.txt
> HBase should provide basic building blocks for multi-row local transactions. Local means
that we do this by co-locating the data. Global (cross region) transactions are not discussed
> After a bit of discussion two solutions have emerged:
> 1. Keep the row-key for determining grouping and location and allow efficient intra-row
scanning. A client application would then model tables as HBase-rows.
> 2. Define a prefix-length in HTableDescriptor that defines a grouping of rows. Regions
will then never be split inside a grouping prefix.
> #1 is true to the current storage paradigm of HBase.
> #2 is true to the current client side API.
> I will explore these two with sample patches here.
> --------------------
> Was:
> As discussed (at length) on the dev mailing list with the HBASE-3584 and HBASE-5203 committed,
supporting atomic cross row transactions within a region becomes simple.
> I am aware of the hesitation about the usefulness of this feature, but we have to start
> Let's use this jira for discussion, I'll attach a patch (with tests) momentarily to make
this concrete.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message