Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
HBase >> mail # user >> Advices for HTable schema

Copy link to this message
Re: Advices for HTable schema
Responses inline
On Monday, July 2, 2012 at 12:53 PM, Jean-Marc Spaggiari wrote:

> Hi Amandeep,
> Thanks for your prompt reply.
> I forgot to add that all the addresses are valid at the same time.
> There is no orders int the addresses. They are all active addresses at
> the same time. If one is not valid any more, it's removed. If there is
> a new one, it's added to the list, not replacing any other. So it's
> not "the last address", but I have to consider all the addresses when
> I will process them.
> Regarding adding the address count in the first CF, don't ask me why I
> have put in in 'a'. I have no clue why I did not tought about adding
> it to 'b' directly. I agree that it's useless to have it in 'a'.
> The idea of the hash as a column name was just to have something to
> put there. It's like the '1' in the second solution. A random number
> will do the same thing.
> I'm accessing the data in 2 ways.
> 1) I acces the person information to update them or retreive all of
> them to display them
> 2) I access only the address the compute some statistiques about it.
> Which mean usually I read ALL the address for one person and not just
> one address at a time.
So, that means that the addresses are accessed independently of the other information and you always access all the addresses together? Or does that mean that the addresses are accessed along with the other information to display or retrieve and they are also accessed separately for the stats calculation?

You could consider the following ideas:

1. Store everything in 'a' and let all addresses go into the column 'a:address'. Increase the versions to N, where N is the max number of addresses you want to store for any user.


2. Store addresses in an entirely different table with the rowkey being user+address. The column qualifier and cell value could be just a simple 1 for the sake of having something there. When you want to get all addresses for a user, you just scan from start key 'user' to end key 'user+1'.

I'm not a fan of the first schema option that you outlined earlier because of the complexity involved in the client code. That approach works with relational databases where you have the ability to do transactions. In the HBase world, not so much.
> So basically, there all the 3 options almost the same thing. If I
> store the number of addresses, I will have more work when I have to
> add/remove one entry, same amount of work when I want to parse the
> entries, and less work when I want to count the entries.
> Difficult choice. I don't find any schema better than the other one
> because all of them have pros and cons. For now, my prefered one is #1
> because it's sound more "natural" to store the number of columns, then
> parse them by name, etc. but I think I need to think about it a little
> be more before taking any decision...
> JM
> 2012/7/2, Amandeep Khurana <[EMAIL PROTECTED] (mailto:[EMAIL PROTECTED])>:
> > Jean-Marc,
> >
> > These are great questions! Find my answers (and some questions for you)
> > inline.
> >
> > -ak
> >
> >
> > On Monday, July 2, 2012 at 12:04 PM, Jean-Marc Spaggiari wrote:
> >
> > > Hi,
> > >
> > > I have a question regarding the best way to design a table.
> > >
> > > Let's imagine I want to store all the people in the world on a database.
> > >
> > > Everyone has a name, last name, phone number, lot of flags (sex, age,
> > > etc.).
> > >
> > > Now, people can have one address, but they can also have 2, or 3, or
> > > even more... But they will never have thousands of addresses. Let's
> > > say, usually, they have between 1 and 10.
> > >
> >
> >
> > The point to think about here is - what will be your read access pattern?
> > Will you always want the latest address? Or will you want all addresses
> > every time? And then also defining the maximum number of addresses to be
> > stored.
> > >
> > > My table is designes like that.
> > >
> > > create 'person', {NAME => 'a', VERSIONS => 1}, {NAME => 'b', VERSIONS