Return-Path: X-Original-To: apmail-hbase-user-archive@www.apache.org Delivered-To: apmail-hbase-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 40D2E19C5D for ; Tue, 26 Apr 2016 16:17:11 +0000 (UTC) Received: (qmail 35462 invoked by uid 500); 26 Apr 2016 16:17:09 -0000 Delivered-To: apmail-hbase-user-archive@hbase.apache.org Received: (qmail 35385 invoked by uid 500); 26 Apr 2016 16:17:09 -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 35373 invoked by uid 99); 26 Apr 2016 16:17:08 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 26 Apr 2016 16:17:08 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id 810A8C0715 for ; Tue, 26 Apr 2016 16:17:08 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.179 X-Spam-Level: * X-Spam-Status: No, score=1.179 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=2, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd4-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx2-lw-us.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id vAPyMu69DO2y for ; Tue, 26 Apr 2016 16:17:06 +0000 (UTC) Received: from mail-wm0-f48.google.com (mail-wm0-f48.google.com [74.125.82.48]) by mx2-lw-us.apache.org (ASF Mail Server at mx2-lw-us.apache.org) with ESMTPS id D11945F247 for ; Tue, 26 Apr 2016 16:17:05 +0000 (UTC) Received: by mail-wm0-f48.google.com with SMTP id e201so2909561wme.0 for ; Tue, 26 Apr 2016 09:17:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=1LwCzpXsTgqWXCKgJJhDZpm/maZspCjYegLhWI7iYF0=; b=Zj3rD93hCz0eTeOCuH4prkfP/WC01FLvDybfWYSLH3IVM0i3M486RioyFQQJRWuJXF XP6hXaWL/jUawnYiNGRtGk+6cso528kMj+8Ibsf2UbQ8UU+KhH9YfC+R4j2CDgjK/eDt M9ik9jeBshXK/tX6qMs1hrvwIVaG0MnIM6j2obwEqcrh0b857Y+qvXmnAWH/zfmCvmlT 8KMtYc5DEvfKV6bEbXSbtXCcbm+/J8qj12A4HqnIAgMG/V/WAdBKQebAesjd4sJatdZ5 OXO63lhE0ri/IQgR7ei44XoOfeG+PRNmQhRyU+kml3fr+hbRRZQPu72HF2GrXFvnVS6T iXaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=1LwCzpXsTgqWXCKgJJhDZpm/maZspCjYegLhWI7iYF0=; b=jzA4zP4kgS44iIOw/VIbbnwqSIZD8Tgczw+l/sZfqYCJQlO4XTdr6hb4ZZTVETbnzq 5DqhZ3A+OL2CT7HImETN2QuZBvTO7LXn5PzdclzS3V5fJ9BUz6z0yoV9YNEUt1vC6t5i WUOTNcls/U+ovBHC2HHiJTonrjBxYPf+SC75FJ2wj+OXAhFYaCHJE9J2UR6Gg4tgi5ij ZcjMm4/6hEmIuwR81lv6deltc/ZZgF/HxFdnnaK5KuxRhlDSWSZ8aXtZpdtwtyLrtea2 reJopKTfp1fInY7HMnYmzRibo//nLvXcvJuLTGbokwNCj5o+Yg/pa7fKFFcFFujshIGG eR6g== X-Gm-Message-State: AOPr4FUP++TDDQWmAdGn9JYWW/UAc4ZLp0MWqWX7G7m8uXIHsyz8K3CX34R5aO9o8QkFAuEKX9tMhTG8uekscg== X-Received: by 10.28.128.143 with SMTP id b137mr18938607wmd.57.1461687418241; Tue, 26 Apr 2016 09:16:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.30.19 with HTTP; Tue, 26 Apr 2016 09:16:38 -0700 (PDT) In-Reply-To: References: From: Nick Dimiduk Date: Tue, 26 Apr 2016 09:16:38 -0700 Message-ID: Subject: Re: Retiring empty regions To: hbase-user Content-Type: multipart/alternative; boundary=001a1141e52c5664900531659f96 --001a1141e52c5664900531659f96 Content-Type: text/plain; charset=UTF-8 I'm looking forward to your talk Vlad. In the mean time, I filed HBASE-15712. We'll get our implementation posted up there. We have these deployed on one of the masters, running daily with cron. @Mikhail, to get this feature into the normalizer, how about this: let's add a min number of regions property to user tables. This can be set when someone creates a table with split points, or maintained manually. The normalizer can use that as a constraint to guide its convergence. On Wed, Apr 20, 2016 at 5:18 PM, Vladimir Rodionov wrote: > >I'd love to hear your thoughts on this design, Vlad. Maybe you'd like to > >write up a post for the blog? Meanwhile, I'm sure of a couple of us on > here > >on the list would appreciate your Cliff's Notes version. I can take this > >into account for my v2 schema design. > > Nick, there will be a presentation on time-series HBase (hbasecon.com) > Come > join us :) > > > On Mon, Apr 4, 2016 at 8:34 AM, Nick Dimiduk wrote: > > > > Crazy idea, but you might be able to take stripped down version of > region > > > normalizer code and make a Tool to run? Requesting split or merge is > done > > > through the client API, and the only weighing information you need is > > > whether region empty or not, that you could find out too? > > > > Yeah, that's the direction I'm headed. > > > > > A bit off topic, but I think unfortunately region normalizer now > ignores > > > empty regions to avoid undoing pre-split on the table. > > > > Unfortunate indeed. Maybe we should be keeping around the initial splits > > list as a metadata attribute on the table? > > > > > With a right row-key design you will never have empty regions due to > TTL. > > > > I'd love to hear your thoughts on this design, Vlad. Maybe you'd like to > > write up a post for the blog? Meanwhile, I'm sure of a couple of us on > here > > on the list would appreciate your Cliff's Notes version. I can take this > > into account for my v2 schema design. > > > > > So Nick, merge on 1.1 is not recommended??? Was working very well on > > > previous versions. Is ProcV2 really impact it that bad?? > > > > How to answer here carefully... I have no reason to believe merge is not > > working on 1.1. I've been on the wrong end of enough "regions stuck in > > transition" support tickets that I'm not keen to put undue stress on my > > master. ProcV2 insures against many scenarios that cause master trauma, > > hence my interest in the implementation details and my preference for > > cluster administration tasks that use it as their source of authority. > > > > Thanks for the thoughts folks. > > -n > > > > On Fri, Apr 1, 2016 at 10:52 AM, Jean-Marc Spaggiari < > > jean-marc@spaggiari.org> wrote: > > > > > ;) That was not the question ;) > > > > > > So Nick, merge on 1.1 is not recommended??? Was working very well on > > > previous versions. Is ProcV2 really impact it that bad?? > > > > > > JMS > > > > > > 2016-04-01 13:49 GMT-04:00 Vladimir Rodionov : > > > > > > > >> This is something > > > > >> which makes it far less useful for time-series databases with > short > > > TTL > > > > on > > > > >> the tables. > > > > > > > > With a right row-key design you will never have empty regions due to > > TTL. > > > > > > > > -Vlad > > > > > > > > On Thu, Mar 31, 2016 at 10:31 PM, Mikhail Antonov < > > olorinbant@gmail.com> > > > > wrote: > > > > > > > > > Crazy idea, but you might be able to take stripped down version of > > > region > > > > > normalizer code and make a Tool to run? Requesting split or merge > is > > > done > > > > > through the client API, and the only weighing information you need > is > > > > > whether region empty or not, that you could find out too? > > > > > > > > > > > > > > > "Short of upgrading to 1.2 for the region normalizer," > > > > > > > > > > A bit off topic, but I think unfortunately region normalizer now > > > ignores > > > > > empty regions to avoid undoing pre-split on the table. This is > > > something > > > > > which makes it far less useful for time-series databases with short > > TTL > > > > on > > > > > the tables. We'll need to address that. > > > > > > > > > > -Mikhail > > > > > > > > > > On Thu, Mar 31, 2016 at 9:56 PM, Nick Dimiduk > > > > wrote: > > > > > > > > > > > Hi folks, > > > > > > > > > > > > I have a table with TTL enabled. It's been receiving data for a > > while > > > > > > beyond the TTL and I now have a number of empty regions. I'd like > > to > > > > drop > > > > > > those empty regions to free up heap space on the region servers > and > > > > > reduce > > > > > > master load. I'm running a 1.1 derivative. > > > > > > > > > > > > The only threads I found on this topic are from circa 0.92 > > timeframe. > > > > > > > > > > > > Short of upgrading to 1.2 for the region normalizer, what's the > > > > > recommended > > > > > > method of cleaning up this cruft? Should I be merging empty > regions > > > > into > > > > > > their neighbor's? Looks like region merge hasn't been migrated to > > > > ProcV2 > > > > > > yet so would be wise to reduce online table activity, or at least > > aim > > > > > for a > > > > > > "quiet period"? Is there a documented process for off-lining and > > > > > deleting a > > > > > > region by name? I don't see anything in the book about it. > > > > > > > > > > > > I experimented with online merge on pseudodist, looks like it's > > > working > > > > > > fine for the most basic case. I'll probably pursue this unless > > > someone > > > > > has > > > > > > some other ideas. > > > > > > > > > > > > Thanks, > > > > > > Nick > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Thanks, > > > > > Michael Antonov > > > > > > > > > > > > > > > --001a1141e52c5664900531659f96--