hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henning Blohm <henning.bl...@zfabrik.de>
Subject Re: Question on efficient, ordered composite keys
Date Wed, 15 Jan 2014 08:24:19 GMT
Until James' reply I wasn't aware of the possibility to use Phoenix Keys 
independently of the rest (which would be a requirement currently). So 
the best choice among existing implementations seemed to be Orderly but 
it looks a little abandoned. I will ping Nick on that.

Thanks,
Henning


On 01/15/2014 01:40 AM, Doug Meil wrote:
> Hey there,
>
> re:  "efficient, correctly ordered, byte[] serialized composite row keys?"
>
> I was the guy behind 7221 and that patch had the first part and the last
> part, but not the middle part (correctly ordered) because this patch
> relied on the HBase build-in implementations which have the aforementioned
> order issue.
>
> James already threw out a good option, but you could also take the 7221
> patch and use it yourself and change the conversions to use Orderly or
> something that has the type conversions that are suitable for your
> purposes.
>
> Once HBase fixes the type conversion issue, some form of built-in utility
> for creating composite keys is critical because building composite keys is
> one of the most asked questions on the dist-list (what 7221 was attempting
> to address).
>
>
>
>
>
> on 1/14/14 4:01 PM, "James Taylor" <jtaylor@salesforce.com> wrote:
>
>> Hi Henning,
>> My favorite implementation of efficient composite row keys is Phoenix. We
>> support composite row keys whose byte representation sorts according to
>> the
>> natural sort order of the values (inspired by Lily). You can use our type
>> system independent of querying/inserting data with Phoenix, the advantage
>> being that when you want to support adhoc querying through SQL using
>> Phoenix, it'll just work.
>>
>> Thanks,
>> James
>>
>>
>> On Tue, Jan 14, 2014 at 7:02 AM, Ted Yu <yuzhihong@gmail.com> wrote:
>>
>>> Please take a look at HBASE-8089 which is an umbrella JIRA.
>>> Some of its subtasks are in 0.96
>>>
>>> bq. claiming that short keys (as well as short column names) are
>>> relevant
>>> bq. Is that also true in 0.94.x?
>>>
>>> That is true in 0.94.x
>>>
>>> Cheers
>>>
>>>
>>> On Tue, Jan 14, 2014 at 6:56 AM, Henning Blohm <henning.blohm@zfabrik.de
>>>> wrote:
>>>> Hi,
>>>>
>>>> for an application still running on Hbase 0.90.4 (but moving to
>>> 0.94.6)
>>> we
>>>> are thinking about using more efficient composite row keys compared
>>> what
>>> we
>>>> use today (fixed length strings with "/" separator).
>>>>
>>>> I ran into http://hbase.apache.org/book/rowkey.design.html claiming
>>> that
>>>> short keys (as well as short column names) are relevant also when
>>> using
>>>> compression (as there is no compression in caches/indices). Is that
>>> also
>>>> true in 0.94.x?
>>>>
>>>> If so, is there some support for efficient, correctly ordered, byte[]
>>>> serialized composite row keys? I ran into HBASE-7221 <
>>>> https://issues.apache.org/jira/browse/HBASE-7221> and HBASE-7692.
>>>>
>>>> For some time it seemed Orderly (https://github.com/ndimiduk/orderly)
>>> was
>>>> suggested but then abandoned again in favor of ... nothing really.
>>>>
>>>> So, in short, do you have any favorite / suggested implementation?
>>>>
>>>> Thanks,
>>>> Henning
>>>>


-- 
Henning Blohm

*ZFabrik Software KG*

T: 	+49 6227 3984255
F: 	+49 6227 3984254
M: 	+49 1781891820

Lammstrasse 2 69190 Walldorf

henning.blohm@zfabrik.de <mailto:henning.blohm@zfabrik.de>
Linkedin <http://www.linkedin.com/pub/henning-blohm/0/7b5/628>
ZFabrik <http://www.zfabrik.de>
Blog <http://www.z2-environment.net/blog>
Z2-Environment <http://www.z2-environment.eu>
Z2 Wiki <http://redmine.z2-environment.net>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message