hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] Updated: (HBASE-1506) [performance] Make splits faster
Date Mon, 05 Oct 2009 20:45:31 GMT

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

stack updated HBASE-1506:

    Attachment: split.patch

This patch implements two things:

1. If the regionserver has something report the master -- a close, a split, etc. -- it does
not wait to send it (Splits are 4 messages, opens are two messages usually -- these are still
sent in a batch but this patch means less baching at the benefit of faster reaction to cluster
2. The lower half of a split is assigned immediately to the local regionserver.  Only the
top half is given to the master to assign.

Splits should run a little faster.  1. above takes away a small piece of the delay.  2. means
that there is half the master/regionserver interaction getting daughter regions back on line.

Will be back with a few numbers.

> [performance] Make splits faster
> --------------------------------
>                 Key: HBASE-1506
>                 URL: https://issues.apache.org/jira/browse/HBASE-1506
>             Project: Hadoop HBase
>          Issue Type: Improvement
>            Reporter: stack
>            Priority: Critical
>             Fix For: 0.20.1, 0.21.0
>         Attachments: split.patch
> Regionservers run splits.  They close the region to split, divide it, and then tell master
about the two new regions.  Master then assigns new regions.  New regions need to come up
in new locations.  Both regions are offline during this time.
> Instead, regionserver might run split as it does now but new, deploy the lower-half on
the current regionserver immediately.  It'd then inform master that it had split, and that
it was serving the lower half.  Master would then take care of assigning the upper half.
> Benefits would be that clients who were accessing the lower half of the split would not
need to go through recalibration.  They'd just keep working.  There'd be disruption for those
keys that landed in the top half of the split only.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message