hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ted Yu (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-4358) Batch Table Alter Operations
Date Sun, 11 Sep 2011 22:42:08 GMT

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

Ted Yu commented on HBASE-4358:
-------------------------------

A variant of HTableDescriptor ctor should be created. The storage for the new HTableDescriptor
is under /hbase/tmp on hdfs.
A new method, possibly called copyAndRename() should be added to HTableDescriptor:
{code}
  public void copyAndRename(final HTableDescriptor htd) {
{code}
This method copies the contents of htd to this HTableDescriptor and renames the .tableinfo
of htd to .tableinfo of this HTableDescriptor.

The following should be done to make multi-family modifications atomic:
1. Create new HTableDescriptor, htd1, whose storage is under /hbase/tmp on hdfs and is a clone
of original HTableDescriptor, htd
2. Perform series of modifications on htd1
3. Assuming there is no error, copy contents of htd1 onto htd and rename the .tableinfo file
under /hbase/tmp using htd.copyAndRename(htd1).
4. If there was error, report back the exception and skip step 3 above

> 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: 4358-v3.txt, HBASE-4358-v2.patch, 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

        

Mime
View raw message