Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
HBase >> mail # user >> HBase value design


Copy link to this message
-
Re: HBase value design
Hi Amit,

It all depends on your usecase ;)

If you always access countIn and countFloat when you access a value, then
put them together to avoid to have to do 2 calls or a scan or a multiget.
But if you never access them together, you might want to separate them to
reduce RCP transfert, etc.
JM
2013/11/28 Amit Sela <[EMAIL PROTECTED]>

> There are a lot of discussions here regarding the row design but I have a
> question about the value design:
>
> Say I have a table t1 with rows r1,r2...rn and family f.
> I also have qualifiers q1,q2...,qm
>
> For each (ri,fi,qi) tuple I want to store a value vi that is a data blob
> that implements Writable and has two members:
> Integer countInt
> Float countFloat
>
> Would you change the design so that I'll have 2m qualifiers i.e.,
> q1_countInt and q1_countFloat etc.
> with IntWritable and FloatWritable values (respectively) ? or stay with the
> data blob ?
>
> Thanks,
>
> Amit.
>
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB