Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 2BD88200C11 for ; Sat, 21 Jan 2017 00:25:53 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id 2A69C160B55; Fri, 20 Jan 2017 23:25:53 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 72DC2160B48 for ; Sat, 21 Jan 2017 00:25:52 +0100 (CET) Received: (qmail 87952 invoked by uid 500); 20 Jan 2017 23:25:51 -0000 Mailing-List: contact user-help@hbase.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@hbase.apache.org Delivered-To: mailing list user@hbase.apache.org Received: (qmail 87940 invoked by uid 99); 20 Jan 2017 23:25:50 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 20 Jan 2017 23:25:50 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id 73BC7C0441 for ; Fri, 20 Jan 2017 23:25:50 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 2.38 X-Spam-Level: ** X-Spam-Status: No, score=2.38 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=2, HTML_OBFUSCATE_05_10=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd1-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id 8LW0D2f0pz39 for ; Fri, 20 Jan 2017 23:25:49 +0000 (UTC) Received: from mail-yw0-f179.google.com (mail-yw0-f179.google.com [209.85.161.179]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id 396605F27D for ; Fri, 20 Jan 2017 23:25:49 +0000 (UTC) Received: by mail-yw0-f179.google.com with SMTP id v200so105402989ywc.3 for ; Fri, 20 Jan 2017 15:25:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=pOrwLXo0bI+jabCmeuzrPNUjCZPAR7JD+GdoiD5KSTA=; b=pOARlhTGjzhB9OoijZAiVHm9nDinnqIrKg8LJ/JRkyHIk5mX6zqgrmUAvHuZPdG1nJ 0vg6b/2/FPOHFeQWScPMjYHdmQpO3TtnDTZJuwPwSQYNb4EjY2rMqc2bBIWZi3mzpabl THQHo8efk7qsQYdYBiBV8Ddhh3p75qaCGh1xuiD+XFuOhj/hstJ+afl+v2K7dwUAfqq5 Yj2LmFUbZ87QVGLdkYBLwNwlRUS7/75od8z+0jSTng2+ylze34rEtUHx8wPcl02Zg9n+ xQ+utWfXxv88URwS/GZ6P/eMXQCsS0c4m7/BHZuRaJlvQCwGMaGoJzlfKhAR2E5bI1Wt q5SQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=pOrwLXo0bI+jabCmeuzrPNUjCZPAR7JD+GdoiD5KSTA=; b=TTkGlCO0B8BasfyD8X1bgWBB0uhkNf21IpNu+ZXWRQg2uItY5Dj+cgy9SL4uFMjCMv veA120XaTIHEhMSGuyElMpejvMCcr25WKNk2moIv9wwPfv9+8AlWAZ+C0vlEDmcToy5c G9O9UzfXHmDp9rOmsEQfOCYm2VwiGIFuoo8ug8Xm7wY891/I1tMEaBph78pxW4boMZ60 X7zkCjIPRR122H0A8ej2zfIEcrukNE1J5RLJnMrio97iZd7jPQQvFzyCc7QzimyBoYgY Z/rlHPeq0FT5LcB+UhhMy+X4gxaMOuTqRxQyAzrrTGe+TGe/mkCoQEA6zLnNP2Gg+WOS 2OzA== X-Gm-Message-State: AIkVDXITS1/EBzWnIt7SbelBd/XykSTJ8X8xz9pF3ToDWfQQcEGZMCOffEzgykq/JwblK3IPjYnrYeu/zkmObA== X-Received: by 10.129.174.90 with SMTP id g26mr15926432ywk.25.1484954745953; Fri, 20 Jan 2017 15:25:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.244.79 with HTTP; Fri, 20 Jan 2017 15:25:45 -0800 (PST) In-Reply-To: References: <6DF64C36-790D-419F-AC4D-B24BF6AD831E@infor.com> From: Ted Yu Date: Fri, 20 Jan 2017 15:25:45 -0800 Message-ID: Subject: Re: Managed region Splitting To: "user@hbase.apache.org" Content-Type: multipart/alternative; boundary=f403045f719a24058c05468ef84b archived-at: Fri, 20 Jan 2017 23:25:53 -0000 --f403045f719a24058c05468ef84b Content-Type: text/plain; charset=UTF-8 For #1, have you searched / polled phoenix mailing list ? You may get more advice there. For #2, see HBASE-4365. Have you read http://hbase.apache.org/book.html#disable.splitting http://hbase.apache.org/book.html#arch.regions.size Cheers On Fri, Jan 20, 2017 at 2:53 PM, Pradheep Shanmugam < Pradheep.Shanmugam@infor.com> wrote: > HI Ted, > > Is this a common solution when using salted tables to change the policy > back to ConstantSizeRegionSplitPolicy.? > Any reason as why the default policy was changes to > IncreasingToUpperBoundRegionSplitPolicy? > When I am doing manual splitting how do I choose the threshold? > > Thanks, > Pradheep > > > > > On 1/20/17, 5:41 PM, "Ted Yu" wrote: > > >For #1, you can consider plugging in ConstantSizeRegionSplitPolicy > >for hbase.regionserver.region.split.policy > > > >For #2, regions are spread across servers. There is no centralized control > >for the underlying table that prevents region splits from happening at the > >same time. > > > >For #3, KeyPrefixRegionSplitPolicy is not effective for salted tables. > > > >Cheers > > > >On Fri, Jan 20, 2017 at 2:29 PM, Pradheep Shanmugam < > >Pradheep.Shanmugam@infor.com> wrote: > > > >> Hi, > >> > >> 1. I have couple of phoenix tables with salting. I am assuming that all > >> the regions will grow uniformly across the region server. > >> Based on above I expect the region splitting to happen across all the > >> region servers at the same time which will impact my performance when > the > >> region size gets bigger. > >> I am considering manual region splitting to avoid this. But the given > that > >> the default split policy is IncreasingToUpperBoundRegionSplitPolicy< > >> https://hbase.apache.org/devapidocs/org/apache/hadoop/ > hbase/regionserver/ > >> IncreasingToUpperBoundRegionSplitPolicy.html>, > >> I cannot really disable the splitting by increasing the > >> hbase.hregion.max.file size to say 100Gb as the the new split size is > going > >> to be the one set by the policy > >> which will be less than 100 Gb several times and the automatic splitting > >> is going to continue. > >> > >> 2. Or altogether should I not consider manual splitting as the chances > of > >> all regions splitting at the same time is not possible if there is > going to > >> be some internal check which will not trigger multiple split(or a > number) > >> for regions of the same table > >> > >> 3. Would using KeyPrefixRegionSplitPolicy >> devapidocs/src-html/org/apache/hadoop/hbase/regionserver/ > >> KeyPrefixRegionSplitPolicy.html#line.34> will be of any better than > >> IncreasingToUpperBoundRegionSplitPolicy >> apache.org/devapidocs/org/apache/hadoop/hbase/regionserver/ > >> IncreasingToUpperBoundRegionSplitPolicy.html> for salted tables. > >> > >> Please advice.. > >> > >> Thanks, > >> pradheep > >> > --f403045f719a24058c05468ef84b--