Thanks Ted. So in effect it is relevant but there is nothing available
OOTB.
On 01/14/2014 04:02 PM, Ted Yu 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
I am definitely considering that (started looking into Phoenix anyway).
Thanks,
Henning
On 01/14/2014 10:01 PM, James Taylor 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
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
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
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
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,
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
