hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Rawson <ryano...@gmail.com>
Subject Re: Parent/child relation - go vertical, horizontal, or many tables?
Date Fri, 11 Feb 2011 00:57:23 GMT
You want to choose the schema that minimizes the # of RPCs you are doing.

-ryan

On Thu, Feb 10, 2011 at 4:55 PM, Jason <urgisb@gmail.com> wrote:
> Hi all,
>
> Let's say I have two entities Parent and Child. There could be many children in one parent
(from hundreds to tens of millions)
> A child can only belong to one Parent.
>
> Typical queries are:
> -Fetch all children from a single parent
> -Find a few children by their keys or values from a single parent
> -Update a single child by child key and it's parent key
>
> And there are no cross-parent queries.
>
> I am trying to figure out what is better schema approach from performance/maintenance
perspective:
>
> 1. One table with one Parent per row. Row key is a parent id. Children are stored in
a single family each under separate qualifier (child id). Would it even work assuming all
children may not fit in memory?
>
> 2. One table. Compound row key parent id/child id. One child per row.
>
> 3. Many tables - one per parent. Row key is a child id.
>
> Thanks!

Mime
View raw message