Return-Path: X-Original-To: apmail-hbase-dev-archive@www.apache.org Delivered-To: apmail-hbase-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 87587934E for ; Tue, 17 Jan 2012 21:50:22 +0000 (UTC) Received: (qmail 99349 invoked by uid 500); 17 Jan 2012 21:50:21 -0000 Delivered-To: apmail-hbase-dev-archive@hbase.apache.org Received: (qmail 99292 invoked by uid 500); 17 Jan 2012 21:50:21 -0000 Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@hbase.apache.org Delivered-To: mailing list dev@hbase.apache.org Received: (qmail 99284 invoked by uid 99); 17 Jan 2012 21:50:21 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 17 Jan 2012 21:50:21 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of yuzhihong@gmail.com designates 74.125.82.169 as permitted sender) Received: from [74.125.82.169] (HELO mail-we0-f169.google.com) (74.125.82.169) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 17 Jan 2012 21:50:14 +0000 Received: by werl4 with SMTP id l4so2495818wer.14 for ; Tue, 17 Jan 2012 13:49:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=tDgT7qZLwV82LAqjqYk2Zq4H6kU9vpkBpTgurYRBHGw=; b=x7dV4LzxeXLVI8FSiBtYsBgSbWM2GHCbFNpB4gFI+deuSIO/Ca+34MRxT0V88CnHmC WJdM6nnpyv1zNAJs/bbZ9O28DuSlGvrcBnNmBssS7u8gaA8pf6DIEwhpv3uhSsPjMEb4 UxkYQV6RvU/rrh50Ih2Bwkqb9jUWJJdlW/VPc= MIME-Version: 1.0 Received: by 10.180.94.102 with SMTP id db6mr30859834wib.0.1326836994156; Tue, 17 Jan 2012 13:49:54 -0800 (PST) Received: by 10.216.51.147 with HTTP; Tue, 17 Jan 2012 13:49:54 -0800 (PST) In-Reply-To: <5D5578DD-FE5D-409C-B4CF-CCAC060D73DE@gmail.com> References: <1326835632.53005.YahooMailNeo@web121703.mail.ne1.yahoo.com> <5D5578DD-FE5D-409C-B4CF-CCAC060D73DE@gmail.com> Date: Tue, 17 Jan 2012 13:49:54 -0800 Message-ID: Subject: Re: Limited cross row transactions From: Ted Yu To: dev@hbase.apache.org Content-Type: multipart/alternative; boundary=f46d0442720ab6286204b6c04f9f X-Virus-Checked: Checked by ClamAV on apache.org --f46d0442720ab6286204b6c04f9f Content-Type: text/plain; charset=ISO-8859-1 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 > >> > >> > > --f46d0442720ab6286204b6c04f9f--