-Re: Question on efficient, ordered composite keys
James Taylor 2014-01-14, 21:01
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.
On Tue, Jan 14, 2014 at 7:02 AM, Ted Yu <[EMAIL PROTECTED]> 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
> On Tue, Jan 14, 2014 at 6:56 AM, Henning Blohm <[EMAIL PROTECTED]
> > Hi,
> > for an application still running on Hbase 0.90.4 (but moving to 0.94.6)
> > are thinking about using more efficient composite row keys compared what
> > 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)
> > suggested but then abandoned again in favor of ... nothing really.
> > So, in short, do you have any favorite / suggested implementation?
> > Thanks,
> > Henning