[
https://issues.apache.org/jira/browse/ACCUMULO-348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13242639#comment-13242639
]
Keith Turner commented on ACCUMULO-348:
---------------------------------------
In 1.3 and 1.4 splitting is mostly a client side operation. The client
contacts tablet servers directly and ask them to split a tablet. For 1.5 I was
thinking of adding a FATE operation for doing splits. The FATE operation would
lock the table, take tablets offline, and then directly modify the metadata
table. This would probably be really fast. The reason to do this as a FATE op
instead of shipping a bunch of split points to a tablet is that its much more
difficult to handle process and machine failure in the tablet.
However since the parallel split code works so well I was thinking of just
making the client side code use this. However the drawback of this approach is
that the addsplits API would need to add a parameter for number of threads. Or
maybe not, maybe the number of the threads could be a function of the number of
splits passed.
> Adding splits to table via the shell with addsplits is very slow when adding
> a lot of split points
> --------------------------------------------------------------------------------------------------
>
> Key: ACCUMULO-348
> URL: https://issues.apache.org/jira/browse/ACCUMULO-348
> Project: Accumulo
> Issue Type: Improvement
> Affects Versions: 1.3.5
> Reporter: Dave Marion
> Priority: Minor
> Fix For: 1.5.0
>
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
