phoenix-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ankit Singhal <ankitsingha...@gmail.com>
Subject Re: slow response on large # of columns
Date Thu, 29 Dec 2016 05:58:28 GMT
Have you checked your query performance without sqlline. As Jonathan also
mentioned, Sqlline has it's own performance issue in terms of reading
metadata.( so probably time spend is actually spent by sqlline in reading
metadata for 3600 columns and printing header)



On Wed, Dec 28, 2016 at 12:04 AM, Mark Heppner <heppner.mark@gmail.com>
wrote:

> If you don't need to query any of the 3600 columns, you could even just
> use JSON inside of a VARCHAR field.
>
> On Mon, Dec 26, 2016 at 2:25 AM, Arvind S <arvind18352@gmail.com> wrote:
>
>> Setup ..
>> hbase (1.1.2.2.4) cluster on azure with 1 Region server. (8core 28 gb
>> ram ..~16gb RS heap)
>> phoenix .. 4.4
>>
>> Observation ..
>> created a table with 3 col composite PK and 3600 float type columns (1
>> per sec).
>> loaded with <5000 lines of data (<100 MB compressed snappy & fast diff
>> encoding)
>>
>> On performing "select * " or select with individually naming each of
>> these 3600 columns the query takes around 2+ mins to just return a few
>> lines (limit 2,10 etc).
>>
>> Subsequently on selecting lesser number of columns the performance seems
>> to improve.
>>
>> is it an anti-pattern to have large number of columns in phoenix tables?
>>
>> *Cheers !!*
>> Arvind
>>
>
>
>
> --
> Mark Heppner
>

Mime
View raw message