Return-Path: 
 <dev-return-28912-apmail-hbase-dev-archive=hbase.apache.org@hbase.apache.org>
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 141379929
	for <apmail-hbase-dev-archive@www.apache.org>;
 Mon, 25 Jun 2012 13:52:44 +0000 (UTC)
Received: (qmail 14575 invoked by uid 500); 25 Jun 2012 13:52:43 -0000
Delivered-To: apmail-hbase-dev-archive@hbase.apache.org
Received: (qmail 14385 invoked by uid 500); 25 Jun 2012 13:52:42 -0000
Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@hbase.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@hbase.apache.org>
List-Post: <mailto:dev@hbase.apache.org>
List-Id: <dev.hbase.apache.org>
Reply-To: dev@hbase.apache.org
Delivered-To: mailing list dev@hbase.apache.org
Received: (qmail 14372 invoked by uid 99); 25 Jun 2012 13:52:42 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 25 Jun 2012 13:52:42 +0000
X-ASF-Spam-Status: No, hits=-0.0 required=5.0
	tests=SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: domain of anoopsj@huawei.com designates
 119.145.14.65 as permitted sender)
Received: from [119.145.14.65] (HELO szxga02-in.huawei.com) (119.145.14.65)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 25 Jun 2012 13:52:35 +0000
Received: from 172.24.2.119 (EHLO szxeml214-edg.china.huawei.com)
 ([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued)
	with ESMTP id AKV90615;
	Mon, 25 Jun 2012 21:52:09 +0800 (CST)
Received: from SZXEML436-HUB.china.huawei.com (10.72.61.64) by
 szxeml214-edg.china.huawei.com (172.24.2.29) with Microsoft SMTP Server (TLS)
 id 14.1.323.3; Mon, 25 Jun 2012 21:50:38 +0800
Received: from SZXEML531-MBX.china.huawei.com ([fe80::61a8:2cb5:62f9:d4a4]) by
 szxeml436-hub.china.huawei.com ([10.72.61.64]) with mapi id 14.01.0323.003;
 Mon, 25 Jun 2012 21:50:35 +0800
From: Anoop Sam John <anoopsj@huawei.com>
To: "dev@hbase.apache.org" <dev@hbase.apache.org>
Subject: RE: Can there be a doMiniBatchDelete in HRegion?
Thread-Topic: Can there be a doMiniBatchDelete in HRegion?
Thread-Index: Ac1OxT/eryzJ59/GQcGgdWd/oro68///uOmAgAIxT1o=
Date: Mon, 25 Jun 2012 13:50:34 +0000
Message-ID: 
 <0CE69E9126D0344088798A3B7F7F808631134BA5@szxeml531-mbx.china.huawei.com>
References: 
 <0CE69E9126D0344088798A3B7F7F808631134337@szxeml531-mbx.china.huawei.com>,<7DD701E1-C664-4905-8B29-00618F8C2DB4@gmail.com>
In-Reply-To: <7DD701E1-C664-4905-8B29-00618F8C2DB4@gmail.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.18.96.95]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected

I have made the new miniBatchDelete () and made the HTable#delete(List<Dele=
te>) to call this new batch delete.
Just tested initially with the one node cluster.  In that itself I am getti=
ng a performance boost which is very much promising.
Only one CF and qualifier.
10K total rows delete with a batch of 100 deletes. Only deletes happening o=
n the table from one thread.
With the new way the net time taken is reduced by more than 1/10
Will test in a 4 node cluster also. I think it will worth doing this change=
.

-Anoop-
________________________________________
From: yuzhihong@gmail.com [yuzhihong@gmail.com]
Sent: Wednesday, June 20, 2012 6:31 PM
To: dev@hbase.apache.org
Cc: dev@hbase.apache.org
Subject: Re: Can there be a doMiniBatchDelete in HRegion?

I think you can issue large number of deletes on the same region and observ=
e whether the proposed new method gives us performance boost.

Thanks



On Jun 20, 2012, at 2:49 AM, Anoop Sam John <anoopsj@huawei.com> wrote:

> Hi Devs
>
>              There is a batch put support in the HRegion level. When the =
put(List<Put>) happens from client, Puts corresponding to one region might =
get grouped together and handled as a batch.[Depending on the availability =
of rowlocks..   code in HRegion#doMiniBatchPut] For this batch there will b=
e single write and sync into the HLog file.
>
>
>
> A similar kind of delete operation, I am not able to see in HRegion. The =
HTable#delete(List<Delete>) groups the Deletes for the same RS and make one=
 n/w call only. But within the RS, there will be N number of delete calls o=
n the region one by one. This will include N number of HLog write and sync.=
 If this also can be grouped can we get better performance for the multi ro=
w delete.  Is there any problem in doing this batch delete? I am not sure a=
ny JIRA is already present for this.
>
>
>
> Note : Hregion#mutateRowsWithLock().. we do batch operations of Puts and =
Deletes(also)
>
>
>
> -Anoop-=