Re: What are some use-cases for JOINs?

2016-10-20 Thread F21

P.S. I meant to say normalizing rather than de-normalizing.

On 21/10/2016 10:36 AM, F21 wrote:

Hey all,

Normally, rather than de-normalizing my data, I prefer to have the 
data duplicated in 2 tables. With transactions, it is quite simple to 
ensure atomic updates to those 2 tables (especially for read-heavy 
apps). This also makes things easier to query and avoids the memory 
limits of hash joins.


Having said that, what are some use-cases of when JOINs should be used?

Cheers,

Francis





What are some use-cases for JOINs?

2016-10-20 Thread F21

Hey all,

Normally, rather than de-normalizing my data, I prefer to have the data 
duplicated in 2 tables. With transactions, it is quite simple to ensure 
atomic updates to those 2 tables (especially for read-heavy apps). This 
also makes things easier to query and avoids the memory limits of hash 
joins.


Having said that, what are some use-cases of when JOINs should be used?

Cheers,

Francis



Re: Scanning big region parallely

2016-10-20 Thread Vivek Paranthaman
Hi,

How to get the Schema out of Hbase using Phoenix driver?
metadata.getSchemas() produce..
http://stackoverflow.com/questions/40123547/phoenixioexception-nomethodexception-deferredfileoutputstramstring-string-fi

On Thu, Oct 20, 2016 at 11:31 AM, Sanooj Padmakumar 
wrote:

> Hi James,
>
> We are loading data from Phoenix tables into in-memory database. Based on
> the query we are finding the number of phoenix input splits (similar to
> what happens inside phoenix MR) and loads the data into in-memory database
> in parallel. So we are looking for ways to further parallelize the scan of
> a larger region.
>
> As you mentioned phoenix does this for all its queries. Can you please
> provide pointers to the phoenix code where this happens ?
>
> Thanks for the prompt response.
>
> Thanks
> Sanooj Padmakumar
>
> On Wed, Oct 19, 2016 at 11:22 PM, James Taylor 
> wrote:
>
>> Hi Sanooj,
>> I'm not sure what you mean by "loading data in our HBase table into
>> in-memory", but Phoenix queries tables in parallel, even within a region
>> depending on how you've configured statistics and guideposts as described
>> here: http://phoenix.apache.org/update_statistics.html
>>
>> Thanks,
>> James
>>
>>
>> On Wednesday, October 19, 2016, Sanooj Padmakumar 
>> wrote:
>>
>>> Hi All
>>>
>>>
>>> We are are loading data in our HBase table into in-memory. For this we
>>> provide a start row and end row and scan the hbase regions. Is there a way
>>> we can scan a big region in parallel to fasten this whole process ? Any
>>> help/pointers on this will be of great help.
>>>
>>> --
>>> Thanks,
>>> Sanooj Padmakumar
>>>
>>
>
>
> --
> Thanks,
> Sanooj Padmakumar
>


Re: Scanning big region parallely

2016-10-20 Thread Sanooj Padmakumar
Hi James,

We are loading data from Phoenix tables into in-memory database. Based on
the query we are finding the number of phoenix input splits (similar to
what happens inside phoenix MR) and loads the data into in-memory database
in parallel. So we are looking for ways to further parallelize the scan of
a larger region.

As you mentioned phoenix does this for all its queries. Can you please
provide pointers to the phoenix code where this happens ?

Thanks for the prompt response.

Thanks
Sanooj Padmakumar

On Wed, Oct 19, 2016 at 11:22 PM, James Taylor 
wrote:

> Hi Sanooj,
> I'm not sure what you mean by "loading data in our HBase table into
> in-memory", but Phoenix queries tables in parallel, even within a region
> depending on how you've configured statistics and guideposts as described
> here: http://phoenix.apache.org/update_statistics.html
>
> Thanks,
> James
>
>
> On Wednesday, October 19, 2016, Sanooj Padmakumar 
> wrote:
>
>> Hi All
>>
>>
>> We are are loading data in our HBase table into in-memory. For this we
>> provide a start row and end row and scan the hbase regions. Is there a way
>> we can scan a big region in parallel to fasten this whole process ? Any
>> help/pointers on this will be of great help.
>>
>> --
>> Thanks,
>> Sanooj Padmakumar
>>
>


-- 
Thanks,
Sanooj Padmakumar