Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Fri, 9 Sep 2011 00:40:08 +0000 (UTC)
From: "Riley Patterson (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: 
 <499683702.5698.1315528808881.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <199150873.5582.1315527008794.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Updated] (HBASE-4358) Batch Table Alter Operations
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/HBASE-4358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Riley Patterson updated HBASE-4358:
-----------------------------------

    Attachment: HBASE-4358.patch

Note that several assumptions changed in TestMasterObserver due to automatically routing single calls through the batched API in order to minimize code redundancy. So I changed TestMasterObserver accordingly.

> Batch Table Alter Operations
> ----------------------------
>
>                 Key: HBASE-4358
>                 URL: https://issues.apache.org/jira/browse/HBASE-4358
>             Project: HBase
>          Issue Type: Improvement
>          Components: ipc, master, shell
>    Affects Versions: 0.92.0
>            Reporter: Riley Patterson
>            Assignee: Riley Patterson
>            Priority: Minor
>         Attachments: HBASE-4358.patch
>
>
> Currently, the RPC provides no way of asking for several table alterations at once, and the master has no way of batch handling alter requests. Thus, when the user requests several changes at the same time (i.e. add these I columns, delete these J columns, and modify these K columns), each region is brought down (I+J+K) times so that it can reflect the new schema. Additionally, multiple writes are made to META, and multiple RPC calls must be made.
> This patch provides batching for these operations, both at the RPC level and within the Master's TableEventHandlers. This involves a bit of reorganization in the TableEventHandler class hierarchy, and a new TableEventHandler, TableMultiFamilyHandler. The net effect ends up being the difference seen here:
> Before patch:
> hbase(main):001:0> alter 'peeps', {NAME => 'rawr'}, {METHOD => 'delete', NAME => 'name'}
> Updating all regions with the new schema...
> 1/1 regions updated.
> Done.
> Updating all regions with the new schema...
> 1/1 regions updated.
> Done.
> 0 row(s) in 2.6450 seconds
> After patch:
> hbase(main):002:0> alter 'peeps', {NAME => 'rawr'}, {METHOD => 'delete', NAME => 'name'}
> Updating all regions with the new schema...
> 1/1 regions updated.
> Done.
> 0 row(s) in 1.1930 seconds
> Regions are only brought down once, and the duration is cut 1/N.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira