Return-Path: X-Original-To: apmail-accumulo-dev-archive@www.apache.org Delivered-To: apmail-accumulo-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id A9936D2C0 for ; Mon, 18 Jun 2012 18:03:43 +0000 (UTC) Received: (qmail 22346 invoked by uid 500); 18 Jun 2012 18:03:43 -0000 Delivered-To: apmail-accumulo-dev-archive@accumulo.apache.org Received: (qmail 22320 invoked by uid 500); 18 Jun 2012 18:03:43 -0000 Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@accumulo.apache.org Delivered-To: mailing list dev@accumulo.apache.org Received: (qmail 22311 invoked by uid 99); 18 Jun 2012 18:03:43 -0000 Received: from issues-vm.apache.org (HELO issues-vm) (140.211.11.160) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 18 Jun 2012 18:03:43 +0000 Received: from isssues-vm.apache.org (localhost [127.0.0.1]) by issues-vm (Postfix) with ESMTP id 6D2981402B8 for ; Mon, 18 Jun 2012 18:03:43 +0000 (UTC) Date: Mon, 18 Jun 2012 18:03:43 +0000 (UTC) From: "Keith Turner (JIRA)" To: dev@accumulo.apache.org Message-ID: <2015624882.25881.1340042623449.JavaMail.jiratomcat@issues-vm> Subject: [jira] [Updated] (ACCUMULO-483) Create purge locality utility MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/ACCUMULO-483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Turner updated ACCUMULO-483: ---------------------------------- Fix Version/s: (was: 1.4.1) 1.4.2 > Create purge locality utility > ----------------------------- > > Key: ACCUMULO-483 > URL: https://issues.apache.org/jira/browse/ACCUMULO-483 > Project: Accumulo > Issue Type: New Feature > Components: client > Reporter: John Vines > Priority: Minor > Labels: newbie > Fix For: 1.4.2 > > > For some high capacity ingest, the desired path is to do some pre-splits, bulk import, and then let it naturally split down the rest of the way. If all of the pre-split tablets made split evenly, then the system will have continuous ranges bundled together on tservers. This poor distribution can impact performance depending on the operations performed. This could be handled in the load balancer, but it could be tricky. You don't want to randomly reassign tablets with any sort of frequency. Rather, you want to do a one-time operation in doing so. Given the initial assignment code is a bit random (needs to be validated), this could easily be done by offlining a table, purging all location records for it from the !METADATA table, and bringing it back online. The balancer will assign the table randomly, at which point the user could force a major compaction to restablish locality (as well some permanence in tablet assignment). -- 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