phoenix-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vikas Agarwal <vi...@infoobjects.com>
Subject Re: Phoenix response time
Date Sat, 06 Sep 2014 05:48:19 GMT
Missed to mention that count query (posted in my last mail) is also taking
very long time to return the count.


On Sat, Sep 6, 2014 at 11:17 AM, Vikas Agarwal <vikas@infoobjects.com>
wrote:

> As I mentioned, schema is nothing but bunch of fields (some being
> integers, longs and text) along with primary key (row key) and I am making
> simple query to get result for a particular primary key, nothing more than
> that.
>
> 0: jdbc:phoenix:localhost> SELECT count(1) FROM table_name;
>
> +------------+
>
> |  COUNT(1)  |
>
> +------------+
>
> | 4667515    |
>
> +------------+
>
> 1 row selected (*132.11 seconds*)
>
>
> On Sat, Sep 6, 2014 at 11:09 AM, Puneet Kumar Ojha <
> puneet.kumar@pubmatic.com> wrote:
>
>>   If you can share the schema,data type,cardinality of each dimension
>> and usual queries, I can help to design a schema with performance of less
>> than 1 sec using Phoenix.
>>
>>
>>
>> Thanks
>>
>>
>>
>>
>>
>> ------ Original message------
>>
>> *From: *James Taylor
>>
>> *Date: *Sat, Sep 6, 2014 10:15 AM
>>
>> *To: *user;
>>
>> *Subject:*Re: Phoenix response time
>>
>>
>>   Vikas,
>> Please post your schema and query.
>> Thanks,
>> James
>>
>> On Fri, Sep 5, 2014 at 9:18 PM, Vikas Agarwal <vikas@infoobjects.com>
>> wrote:
>> > Ours is also a single node setup right now and as of now there are less
>> than
>> > 1 million rows which is expected to grow around 100m at minimum.
>> >
>> > I am aware of secondary indexes but when I am querying on primary/row
>> key,
>> > why would it take so much time?
>> >
>> > I am directly querying using sqlline for Phoenix and hbase shell for
>> HBase
>> > query. I am not expecting to do any fine tuning for such small dataset.
>> I am
>> > assumimg a minimum performance level out of the box.
>> >
>> > On Friday, September 5, 2014, yeshwanth kumar <yeshwanth43@gmail.com>
>> wrote:
>> >>
>> >> 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 <vikas@infoobjects.com>
>> >> wrote:
>> >>>
>> >>> Hi,
>> >>>
>> >>> Preface: We are testing phoenix using Hortonworks distribution for
>> HBase
>> >>> on Amazon EC2 instance (r3.large, 2 CPU/15 GB RAM).
>> >>>
>> >>> With contrast to performance benchmarks, 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
>> >>
>> >>
>> >
>> >
>> > --
>> > 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
>> >
>> >
>>
>
>
>
> --
> 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
>
>


-- 
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

Mime
View raw message