Return-Path: 
 <dev-return-42396-apmail-hbase-dev-archive=hbase.apache.org@hbase.apache.org>
X-Original-To: apmail-hbase-dev-archive@www.apache.org
Delivered-To: apmail-hbase-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 2AAEA10B83
	for <apmail-hbase-dev-archive@www.apache.org>;
 Sat, 21 Dec 2013 20:26:58 +0000 (UTC)
Received: (qmail 62560 invoked by uid 500); 21 Dec 2013 20:26:57 -0000
Delivered-To: apmail-hbase-dev-archive@hbase.apache.org
Received: (qmail 62505 invoked by uid 500); 21 Dec 2013 20:26:56 -0000
Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@hbase.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@hbase.apache.org>
List-Post: <mailto:dev@hbase.apache.org>
List-Id: <dev.hbase.apache.org>
Reply-To: dev@hbase.apache.org
Delivered-To: mailing list dev@hbase.apache.org
Received: (qmail 62496 invoked by uid 99); 21 Dec 2013 20:26:56 -0000
Received: from minotaur.apache.org (HELO minotaur.apache.org) (140.211.11.9)
    by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 21 Dec 2013 20:26:56 +0000
Received: from localhost (HELO mail-wg0-f48.google.com) (127.0.0.1)
  (smtp-auth username apurtell, mechanism plain)
  by minotaur.apache.org (qpsmtpd/0.29) with ESMTP;
 Sat, 21 Dec 2013 20:26:56 +0000
Received: by mail-wg0-f48.google.com with SMTP id z12so3736843wgg.27
        for <dev@hbase.apache.org>; Sat, 21 Dec 2013 12:26:54 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20130820;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :content-type;
        bh=agrlkb3TDzP5wf/CX++ymDvWSVPOakRu8TkGK5vMnLw=;
        b=j7CbI7Hes1vBL+chQC0BxEqCJkWse3++R+J3TiYkbFShR9KqwU8xXqwcPIbTco6VJW
         dEUQ/X7Sok3FS6Nb6aYF/ND44I4YTpAVxeA1+8S+iOp61iVWh420/VRo1+IbI0kIHCWv
         wIdKFhsEJGql5eu1VYy1T8WpNaoKtd8giu5zbyacV3PtZljwAbimsCvib4VBdhn/iKav
         ogEzQ8njkbb8EZWtk4RkviCSXJevsP+YIUmW+l+Va59mxNZmWCExKvd2G2BH/+fqj+xQ
         OXeUSxCw3TrYwv1bCeBlKx2ejO9iJxOmABnHPoNPNsyQInoxoP/eWMcl/JHJsVVEIyZc
         qsIg==
X-Received: by 10.180.185.101 with SMTP id fb5mr13161124wic.11.1387657614691;
 Sat, 21 Dec 2013 12:26:54 -0800 (PST)
MIME-Version: 1.0
Received: by 10.227.152.8 with HTTP; Sat, 21 Dec 2013 12:26:14 -0800 (PST)
In-Reply-To: <2013122123172401234313@126.com>
References: <2013122123172401234313@126.com>
From: Andrew Purtell <apurtell@apache.org>
Date: Sat, 21 Dec 2013 12:26:14 -0800
Message-ID: 
 <CA+RK=_CUDYvsMyN0TjbEib5yfEgcq7z=GRBYMLjp91UH=Qtmvw@mail.gmail.com>
Subject: Re: About HBASE-3149
To: "dev@hbase.apache.org" <dev@hbase.apache.org>,
 sohomodern <sohomodern@126.com>
Content-Type: multipart/alternative; boundary=001a11c2448e31951304ee11370c

--001a11c2448e31951304ee11370c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Bear in mind that how many files you'll have open simultaneously is a
function of number of regions, number of column families, and how
compaction organizes the HBase files on disk (the strategy in effect and
its parameters, the current ingest rate, and so on). You call ballpark this
as such: If you have one column family in a table, and store data into all
the regions, then you will have one file open on the cluster per region, or
more. If you have 100,000 column families in a table, and store data into
all the regions and CFs, then you will have 100,000 files open on the
cluster per region, *or more*. You will run into OS and HDFS levels
attempting this, I don't recommend it.

I don't think any reasonable schema design needs produce a requirement for
100,000 column *families*. You can have any number of keys with
<column>:<qualifier> in a column family, varying the <qualifier> to 100,000
or 1,000,000 or more unique values is no problem. Can you say more about
what you are trying to accomplish?


On Sat, Dec 21, 2013 at 7:17 AM, =E4=B9=83=E5=B2=A9 <sohomodern@126.com> wr=
ote:

> Hi,
>    Can anybody tell me if future HBase release will integrate 3149 for
> Make flush decisions per column family=EF=BC=9F
>
>   By the way, for current HBase, if the simultaneous flush is the only
> issue? I mean, to create 100000 CFs will not be a problem, right?
>
>   Thanks in advance!
>
>
>
>
>
> N.Y.




--=20
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

--001a11c2448e31951304ee11370c--