phoenix-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Taylor <jamestay...@apache.org>
Subject Re: Composite rowkey and salting
Date Wed, 12 Feb 2014 19:46:01 GMT
Yes, I believe the fix will help also in the case of a partial match on
primary key columns. But the particular case I tested was a complete match
on a composite primary key, in which case the salt byte is known. On a
partial match, we'd do skip scans for each salt bucket and then do a merge
sort on the results. By default, if your leading column in your primary key
constraint isn't used in the query, a skip scan won't be done. Sometimes,
depending on the cardinality of the column values, it'd be better if it
did. You can override this with the SKIP_SCAN hint. There's a bit more
detail here:
http://phoenix.incubator.apache.org/faq.html#/Why_isnt_my_query_doing_a_RANGE_SCAN

Thanks,
James


On Wed, Feb 12, 2014 at 11:26 AM, Skanda Prasad
<skanda.ganapathy@gmail.com>wrote:

>  Hi James,
>
> Does the fix work for a composite key? The reason I'm asking this question
> is that     the salt is generated using composite key (x,y) but when I just
> look up on x, is it possible to identify the bucket? Please correct me if
> I'm wrong..
>
> Thanks,
> Skanda
>  ------------------------------
> From: James Taylor <jamestaylor@apache.org>
> Sent: 13-02-2014 00:42
> To: user@phoenix.incubator.apache.org
> Subject: Re: Composite rowkey and salting
>
>   Hi Skanda,
> Yes, there was actually a bug here that was preventing a point lookup for
> salted tables: https://issues.apache.org/jira/browse/PHOENIX-20
>
> It's been fixed and is in our release candidate build for 2.2.3. Would be
> great if you could verify that this solves your issue.
>
> Thanks,
> James
>
>
> On Wed, Feb 12, 2014 at 10:46 AM, Skanda <skanda.ganapathy@gmail.com>wrote:
>
>> Hi
>> Assume I have a table with composite keys, say (x,y) salted into 3
>> buckets. I understand that the salt is prepended to the actual rowkey. Now
>> when I try to lookup the table for x, will phoenix still do a range scan in
>> 3 regions to fetch the result? How is the hash derived, using x or x,y?
>> Ideally I want to specify the hash component of the composite key,in this
>> case x thereby ensuring identical x's fall into the same region.Is it
>> possible in phoenix?
>>
>> Regards,
>> Skanda
>>
>
>

Mime
View raw message