Thanks JD, I'm using 0.1.3 currently, will upgrade to 0.2 soon. I tried scanner in 0.1.3, seems not very efficient on performance? Reading all serialized objects from just one column is much faster than reading from a whole column family with scanner.
From: "Jean-Daniel Cryans" <[EMAIL PROTECTED]> Subject: Re: table design questions Date: Mon, 14 Jul 2008 22:47:12 -0400 > Zhao, > > The scanner returns whole families and I added this feature to getRow for > 0.2.0 > > J-D > > On Mon, Jul 14, 2008 at 10:40 PM, ZhaoWei <[EMAIL PROTECTED]> wrote: > > > I think it is not easy to get a user's all orders with this schema. There > > is no API to > > get all cells of a column family. > > > > From: "Naama Kraus" <[EMAIL PROTECTED]> > > Subject: Re: table design questions > > Date: Mon, 14 Jul 2008 20:51:49 +0300 > > > > > Hi Pavel, > > > > > > I am thinking there could be another option to add to list: > > > > > > Maintain all orders in users table in a single family named 'orders', > > each > > > order in a separate column member. For each order, have the order id be > > the > > > column name (e.g. orders:12345). Cell value will be a serialization of > > the > > > order object. You'll need the order object to implement > > > org.apache.hadoop.io.Writable. > > > > > > Naama > > > > > > On Mon, Jul 14, 2008 at 7:24 PM, Jean-Daniel Cryans <[EMAIL PROTECTED]> > > > wrote: > > > > > > > Answers inline. > > > > > > > > J-D > > > > > > > > On Mon, Jul 14, 2008 at 12:16 PM, Pavel Lysov <[EMAIL PROTECTED]> > > wrote: > > > > > > > > > Hi all, > > > > > > > > > > > > Hey! > > > > > > > > > > > > > > > > > > > I found that I can not stop thinking in RDBM way while designing > > tables > > > > for > > > > > the application I am working on, so that I need your help. Can you > > please > > > > > take a look at the tables below and advice what approach you think is > > > > doable > > > > > and good enough? > > > > > > > > > > There's should be USERS table I think, something simple for now: > > > > > > > > > > USER_ID: > > > > > profile: > > > > > email > > > > > first_name > > > > > last_name > > > > > > > > > > Then we need to store a huge list of user's orders, here's where I am > > > > > starting to doubt. Can it have many orders in the same USERS table? > > Does > > > > > HBase (bigtable) allow us to have schema like the following: > > > > > USER_ID: > > > > > profile: > > > > > first_name > > > > > last_name > > > > > orders: > > > > > order_1: > > > > > date > > > > > details > > > > > product > > > > > price > > > > > order_2: > > > > > date > > > > > details > > > > > product > > > > > price > > > > > > > > > > > > You can't do that. > > > > > > > > > > > > > > > > > > > > > > > If idea above is bad (I couldn't find API that creates nested column > > > > > families and assume that is not possible), it probably could be > > another > > > > > table for orders: > > > > > ORDER_ID: > > > > > user: > > > > > id > > > > > first_name > > > > > last_name > > > > > order: > > > > > date > > > > > details > > > > > product > > > > > price > > > > > > > > > > > > > > > > > > This way it will require additional work getting orders for certain > > user, > > > > > so the third variant would have composite row key, composed of > > USER_ID > > > > and > > > > > ORDER_ID: > > > > > USER_ID__ORDER_ID: > > > > > order: > > > > > date > > > > > details > > > > > product > > > > > price > > > > > profile: > > > > > first_name > > > > > last_name > > > > > > > > > > > > This last version will effectively group user's orders together. Having > > the > > > > date in the row key just after the user id would even sort it by date > > which > > > > is not bad. > > > > > > > > > > > > > > > > > > The last table variant will be scanned using HScannerInterface, so > > it's > > > > > relatively easy to get all orders for given user I think. How do you > > > > think > > > > > is it fine to create such kind of composite row keys? > > > > > > > > > > Here's where I am. What am I missing? Can you please share your > > thoughts > > > > on > > > > > tables design, you would probably design them in other way? > > > > > > > > > > > > > > > > Another schema would be to have orders data in your user table like > > this > > > > (but what you already have isn't bad): > > > > > > > > USER_ID: > > > > profile: > > > > email > > > > first_name > > > > last_name > > > > order_date: > > > > all ORDER_IDs > > > > order_details > > > > all ORDER_IDs > > > > etc > > > > > > > > > > > > > > > > > > > > > > > Thank you! > > > > > Pavel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > oo 00 oo 00 oo 00 oo 00 oo 00 oo 00 oo 00 oo 00 oo 00 oo 00 oo 00 oo 00 > > oo > > > 00 oo 00 oo > > > "If you want your children to be intelligent, read them fairy tales. If > > you > > > want them to be more intelligent, read them more fairy tales." (Albert > > > Einstein) > >
