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.bul...@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.

Reply via email to