I don't know if it is good or bad but we went down a route of all keys are prefixed or postfixed with "customerId"....prefixed if you want their data more isolated or postfixed if you want them sharing the same grid more and more.
We had some shared tables that are not postfixed nor prefixed and are only touched by a committee when needed for everyone...obviously tradeoff in doing that. Later, Dean -----Original Message----- From: Otis Gospodnetic [mailto:[email protected]] Sent: Friday, June 17, 2011 9:55 PM To: [email protected]; [email protected] Subject: Re: any multitenancy suggestions for HBase? Hi Bill, At the recent HBase hackathon in Berlin there was some word of ACLs in (the next release of?) HBase from the Trend Micro guys, I believe. Check this: http://search-hadoop.com/?q=acl&fc_project=HBase&fc_type=jira Otis -- We're hiring HBase / Hadoop / Hive / Mahout engineers with interest in Big Data Mining and Analytics http://blog.sematext.com/2011/04/18/hiring-data-mining-analytics-machine-learning-hackers/ >________________________________ >From: Bill Graham <[email protected]> >To: [email protected] >Sent: Monday, June 13, 2011 6:31 PM >Subject: any multitenancy suggestions for HBase? > >Hello there, > >We have a number of different groups within our organization who will soon >be working within the same HBase cluster and we're trying to set up some >best practices to keep thinks organized. Since there are no HBase ACLs and >no concept of multiple databases in the cluster, we're looking to propose a >simple convention that will hopefully keep people from stepping on each >others toes (or worse!). > >Does anyone have any best/worst practices they're willing to share w.r.t. >thing likes table/column naming schemes in a multitenant environment? For >table names for example, is there anything better than a basic dot-delimited >naming convention with the group name as the first token? > >Also, I assume there's no performance cost with using long table names like >there is with long CF:col names. Please let me know if that's not the case. > >thanks, >Bill > > > This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.
