Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Sat, 28 Jan 2012 00:21:10 +0000 (UTC)
From: "Lars Hofhansl (Commented) (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: 
 <581153891.2822.1327710070951.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1174652881.54649.1326934359800.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (HBASE-5229) Explore building blocks for
 "multi-row" local transactions.
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Lars Hofhansl commented on HBASE-5229:
--------------------------------------

@Todd: Making split row determination pluggable is a good idea. Not sure how this would interact with the possibility of choosing explicit split points through the HBase shell, would need to disable that (unless the split policy supports it).

Would also need to work on a per table basis.

The pie-in-the-sky sounds cool and also like a rewrite of HBase. :)  (You mean "bar" being the unit of atomicity - not "baz", right? 

@Stack: I hear you. Means that the client and data modeling would have to change completely if it needs transactions.

                
> 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 here.
> 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 somewhere.
> 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