You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@accumulo.apache.org by "Keith Turner (JIRA)" <ji...@apache.org> on 2018/02/09 22:07:00 UTC

[jira] [Commented] (ACCUMULO-4808) Add splits to table at table creation.

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

Keith Turner commented on ACCUMULO-4808:
----------------------------------------

Create table is a FATE operation. FATE operation are persisted in zookeeper and therefore should be small.  So it would not be good to include table splits in a FATE repo as this could be a large amount of data.  One possible way to avoid this is to store the split points in a file in HDFS before the FATE op is started.  The master could do this and store it in a accumulo dir in dfs (just randomly pick a volume).  The FATE repo would then only need to store the file path in ZK.

> Add splits to table at table creation.
> --------------------------------------
>
>                 Key: ACCUMULO-4808
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-4808
>             Project: Accumulo
>          Issue Type: Sub-task
>          Components: master, tserver
>            Reporter: Mark Owens
>            Assignee: Mark Owens
>            Priority: Major
>             Fix For: 2.0.0
>
>
> Add capability to add table splits at table creation. Recent changes now allow iterator and locality groups to be created at table creation. Do the same with splits. Comment below from [ACCUMULO-4806|https://issues.apache.org/jira/browse/ACCUMULO-4806] explains the motivation for the request:
> {quote}[~etcoleman] added a comment - 2 hours ago
> It would go al long way if the splits could be added at table creation or when table is offline.  When the other API changes were made by Mark, I wondered if this task could also could be done at that time - but I believe that it was more complicated.
> The delay is that when a table is created and then the splits added and then taken offline there is a period proportional to the number of splits as they are off-loaded from the tserver where they originally got assigned.  (The re-online with splits distributed across the cluster is quite fast)
> If the splits could be added at table creation, or while the table is offline so that the delay for shedding the tablets could be avoided, then the need to perform the actual import offline would not be as necessary.
>  
> {quote}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)