phoenix-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bulvik, Noam" <Noam.Bul...@teoco.com>
Subject RE: CSV bulk loading question
Date Tue, 10 Mar 2015 09:11:35 GMT
Thanks James
Any explanation to why do we see this difference after all we are writing the same data in
both cases

-----Original Message-----
From: James Taylor [mailto:jamestaylor@apache.org]
Sent: Tuesday, March 10, 2015 11:08 AM
To: user
Subject: Re: CSV bulk loading question

Hi Noam,
We're tuning CSV bulk load in PHOENIX-1711, but it won't get you a 7x speedup (maybe 30% at
the most if we're lucky). The other thing you'd lose by writing all values into one column
is incremental update speed which may or may not apply for your use case. To update a single
value, you'd need to read the existing value, stitch in the new value and write it back out
again.

If your use case doesn't require incremental update, you can write them all in a single column
and still query and access them individually. The easiest way I can think of doing this would
be to store them in a protobuf and serialize it into a VARBINARY column.
Then create a built-in function that allows accessing them positionally or by name. Once you
have that, could even add functional indexes over individual fields (obviously with the overhead
that indexes add). PHOENIX-477 is about formalizing this as SQL Structs which this could become
if taken far enough. Even without this, just having a set of built-in functions that work
off of a protobuf would be a useful first step and a great contribution.

Thanks,
James


On Mon, Mar 9, 2015 at 11:03 PM, Bulvik, Noam <Noam.Bulvik@teoco.com> wrote:
> Hi,
>
>
>
> We are using the CSV bulk  loading (MR) to load our data. we have a
> table with 50 columns and We did some testing to understand the
> factors on the performance of loading.
>
> We compared two cases
>
> A -  each column in the data will be a column in hbase table
>
> B – take all non-key column and put them in one column in the hbase
> table
>
>
>
> We saw that the second option we 7 times faster than the first one and
> consumed les CPU resources.
>
>
>
> Does this make sense? Can we do something to tune the system so option
> A will run faster? (we prefer it this way because it enables us to
> query and filter over all data columns)
>
>
>
>
>
> Regards,
>
>
>
> Noam Bulvik
>
>
>
>
> ________________________________
>
> PRIVILEGED AND CONFIDENTIAL
> PLEASE NOTE: The information contained in this message is privileged
> and confidential, and is intended only for the use of the individual
> to whom it is addressed and others who have been specifically authorized to receive it.
> If you are not the intended recipient, you are hereby notified that
> any dissemination, distribution or copying of this communication is
> strictly prohibited. If you have received this communication in error,
> or if any problems occur with transmission, please contact sender. Thank you.

________________________________

PRIVILEGED AND CONFIDENTIAL
PLEASE NOTE: The information contained in this message is privileged and confidential, and
is intended only for the use of the individual to whom it is addressed and others who have
been specifically authorized to receive it. If you are not the intended recipient, you are
hereby notified that any dissemination, distribution or copying of this communication is strictly
prohibited. If you have received this communication in error, or if any problems occur with
transmission, please contact sender. Thank you.
Mime
View raw message