Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Tue, 10 Oct 2017 14:48:00 +0000 (UTC)
From: "Mike Drob (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.13097730.1503703218000.18301.1507646880090@Atlassian.JIRA>
In-Reply-To: <JIRA.13097730.1503703218000@Atlassian.JIRA>
References: <JIRA.13097730.1503703218000@Atlassian.JIRA> <JIRA.13097730.1503703218564@jira-lw-us.apache.org>
Subject: [jira] [Commented] (HBASE-18693) adding an option to
 restore_snapshot to move mob files from archive dir to working dir
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Tue, 10 Oct 2017 14:48:05 -0000


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

Mike Drob commented on HBASE-18693:
-----------------------------------

The rubocop & ruby-lint warnings look fine to ignore for now. We'll need to do a major cleanup pass later on line length anyway.

> adding an option to restore_snapshot to move mob files from archive dir to working dir
> --------------------------------------------------------------------------------------
>
>                 Key: HBASE-18693
>                 URL: https://issues.apache.org/jira/browse/HBASE-18693
>             Project: HBase
>          Issue Type: Improvement
>          Components: mob
>    Affects Versions: 2.0.0-alpha-2
>            Reporter: huaxiang sun
>            Assignee: huaxiang sun
>         Attachments: HBASE-18693.master.001.patch
>
>
> Today, there is a single mob region where mob files for all user regions are saved. There could be many files (one million) in a single mob directory. When one mob table is restored or cloned from snapshot, links are created for these mob files. This creates a scaling issue for mob compaction. In mob compaction's select() logic, for each hFileLink, it needs to call NN's getFileStatus() to get the size of the linked hfile. Assume that one such call takes 20ms, 20ms * 1000000 = 6 hours. 
> To avoid this overhead, we want to add an option so that restore_snapshot can move mob files from archive dir to working dir. clone_snapshot is more complicated as it can clone a snapshot to a different table so moving that can destroy the snapshot. No option will be added for clone_snapshot.


--
This message was sent by Atlassian JIRA
(v6.4.14#64029)