Mailing-List: contact user-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@hbase.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <770786.6071.qm@web65514.mail.ac4.yahoo.com>
Date: Thu, 16 Jun 2011 11:08:00 -0700 (PDT)
From: Andrew Purtell <apurtell@apache.org>
Reply-To: apurtell@apache.org
Subject: Re: any multitenancy suggestions for HBase?
To: user@hbase.apache.org, billgraham@gmail.com
In-Reply-To: <BANLkTimh_yN9eePTj5b_W=XxFyP3uZmqXw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

> Since there are no HBase ACLs =0A=0AThis is true only until HBASE-3025 is=
 ready and goes in, post 0.92. It may not be of immediate help now but yes =
HBase will have ACLs. They are on the roadmap.=0A=0ABest regards,=0A=0A    =
- Andy=0A=0AProblems worthy of attack prove their worth by hitting back. - =
Piet Hein (via Tom White)=0A=0A=0A--- On Tue, 6/14/11, Barney Frank <barney=
franks1@gmail.com> wrote:=0A=0A> From: Barney Frank <barneyfranks1@gmail.co=
m>=0A> Subject: Re: any multitenancy suggestions for HBase?=0A> To: user@hb=
ase.apache.org, billgraham@gmail.com=0A> Date: Tuesday, June 14, 2011, 5:04=
 AM=0A> Our implementation supports multiple=0A> customers that share the s=
ame tables=0A> and column families.=A0 We use the customerId as the=0A> fir=
st token of the Row Id=0A> i.e. "CUST123|someOtherRowQualifier".=A0 For all=
=0A> customer queries, we add=0A> their customerId as the row prefix and, o=
f course, ensure=0A> that they are=0A> authorized within our app.=0A> =0A> =
On Mon, Jun 13, 2011 at 5:31 PM, Bill Graham <billgraham@gmail.com>=0A> wro=
te:=0A> =0A> > Hello there,=0A> >=0A> > We have a number of different group=
s within our=0A> organization who will soon=0A> > be working within the sam=
e HBase cluster and we're=0A> trying to set up some=0A> > best practices to=
 keep thinks organized. Since there=0A> are no HBase ACLs=A0 and=0A> > no c=
oncept of multiple databases in the cluster, we're=0A> looking to propose a=
=0A> > simple convention that will hopefully keep people from=0A> stepping =
on each=0A> > others toes (or worse!).=0A> >=0A> > Does anyone have any bes=
t/worst practices they're=0A> willing to share w.r.t.=0A> > thing likes tab=
le/column naming schemes in a=0A> multitenant environment? For=0A> > table =
names for example, is there anything better than=0A> a basic=0A> > dot-deli=
mited=0A> > naming convention with the group name as the first=0A> token?=
=0A> >=0A> > Also, I assume there's no performance cost with using=0A> long=
 table names like=0A> > there is with long CF:col names. Please let me know=
 if=0A> that's not the case.=0A> >=0A> > thanks,=0A> > Bill=0A> >=0A>