Mailing-List: contact user-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@hbase.apache.org
Received-SPF: pass (nike.apache.org: domain of static.void.dev@gmail.com
 designates 209.85.210.173 as permitted sender)
Message-ID: <4E512B4F.2080208@gmail.com>
Date: Sun, 21 Aug 2011 08:59:11 -0700
From: Mark <static.void.dev@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6;
 rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
To: user@hbase.apache.org
Subject: Number of tables
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

We are logging all user actions into hbase. These actions include 
searches, product views and clicks.

We are currently storing them in one table with row keys like so: 
"#{type}/#{user}/#{time}", where type is either click, search, view and 
user is the current user logged in. Obviously using this method lead to 
region hot spotting as the start of each key is fairly static. This got 
me to thinking on what alternatives ways I could model this type of data 
and I was hoping I could get some suggestions from the community.

Which would be more advisable?

1) Keep the current all logs go to one table pattern that is describe above.
2) Keep the current all logs go to one table pattern that is describe 
above but switch the type and user fields which would lead to more 
randomized keys thus reducing hot spots
3) Create separate tables for each type of log we are saving... ie have 
search table, click table, view table.

Our use case does not require us searching across multiple types so I'm 
leaning towards #3 now but I was wondering if there were any cons to 
using this method? Is it worse to have more tables than less?

Thanks for help

-M