hi vikas, we used phoenix on a 4 core/23Gb machine, as a single node setup. used HDP 2.1 our table has 50-70M rows, select on that table took less than 2 seconds. Aggregation queries took less than 8 seconds. for achieving good performance we created secondary index on the table.
make sure you finetuned hbase, enabling compression on the data makes a difference in response. if u distribute the data and load over all regions in hbase, look at the performance tips mentioned in phoenix blog -yeshwanth Cheers, Yeshwanth On Fri, Sep 5, 2014 at 5:42 PM, Vikas Agarwal <vi...@infoobjects.com> wrote: > Hi, > > Preface: We are testing phoenix using Hortonworks distribution for HBase > on Amazon EC2 instance (r3.large <http://aws.amazon.com/ec2/pricing/>, 2 > CPU/15 GB RAM). > > With contrast to performance benchmarks > <http://phoenix.apache.org/performance.html>, I found Phoenix to be very > slow in querying even on primary key or row key. So, tried to increase the > RAM for HBase and Phoenix and increasing the CPU and RAM by upgrading the > EC2 machine type to r3.xlarge (4 CPU, 30 GB RAM). Results were like this: > > Time takes in returning result of query on row key: > With Storm running and very less RAM available: *50 sec* > > With Storm stopped and RAM available to Phoenix and HBase: *18 sec* > > With new machine of next higher category (4 CPU and 30 GB RAM): *8 sec* > > Pure HBase query by row key with Storm stopped and (2 CPU, 15 GB RAM): *0.0150 > seconds*. :) > > So, the difference seems to be many fold of what native HBase is providing > to us. I am not able to understand how it can be possible? What I am > missing here? > > -- > Regards, > Vikas Agarwal > 91 – 9928301411 > > InfoObjects, Inc. > Execution Matters > http://www.infoobjects.com > 2041 Mission College Boulevard, #280 > Santa Clara, CA 95054 > +1 (408) 988-2000 Work > +1 (408) 716-2726 Fax > >
