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 >> Miserable Performance of gets


Copy link to this message
-
Re: Miserable Performance of gets
Version is 0.94.1

Yes, the gets are issued against the second table scanning the first table
On Wed, Mar 6, 2013 at 10:27 AM, Ted Yu <[EMAIL PROTECTED]> wrote:

> Which HBase version are you using ?
>
> bq. But even for 20 gets
> These were issued against the second table ?
>
> Thanks
>
> On Tue, Mar 5, 2013 at 8:36 PM, kiran <[EMAIL PROTECTED]> wrote:
>
> > Dear All,
> >
> > I had some miserable experience with gets (batch gets) in hbase. I have
> two
> > tables with different rowkeys, columns are distributed across the two
> > tables.
> >
> > Currently what I am doing is scan over one table and get all the rowkeys
> in
> > the first table matching my filter. Then issue a batch get on another
> table
> > to retrieve some columns. But even for 20 gets, the performance is like
> > miserable (almost a second or two for 20 gets which is not acceptable).
> > But, scanning even on few thousands of rows is getting completed in
> > milliseconds.
> >
> > My concern is for about 20 gets if it takes second or two,
> > How can it scale ??
> > Will the performance be the same even if I issue 1000 gets ??
> > Is it advisable in hbase to avoid gets ??
> >
> > I can include all columns in only one table and do a scan also, but
> before
> > doing that I need to really understand the issue...
> >
> > Is scanning a better solution for scalability and performance ???
> >
> > Is it advisable not to do joins or normalizations in NOSQL databases,
> > include all the data in only table and not do joins with another table ??
> >
> >
> > --
> > Thank you
> > Kiran Sarvabhotla
> >
> > -----Even a correct decision is wrong when it is taken late
> >
>

--
Thank you
Kiran Sarvabhotla

-----Even a correct decision is wrong when it is taken late
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