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" <jtay...@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 <yuzhih...@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.bl...@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
>> >
>>

Reply via email to