hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Clint Morgan (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HBASE-661) Allow to specify a user supplied row key comparator for a table
Date Tue, 09 Sep 2008 22:31:44 GMT

    [ https://issues.apache.org/jira/browse/HBASE-661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12629639#action_12629639
] 

Clint Morgan commented on HBASE-661:
------------------------------------

This seems easy enough at first glance. Just associate an (optional) WritableCompartor<byte[]>
with each table. If a table has this comparator then use it (this logic seems to belong in
the new HStoreKey.compareTwoRowKeys).

Things get more tricky I think when taking the META table into account. I suppose I need to
rework the way META rows are being compared to use the tables comparator for the row's bits
in each meta key.

So If I have two tables A, and B with 2 regions each, and B has a custom, reverse, comparator,
then I want a META laid out like:

A,1,5
A,5,
B,9,5
B,5,

So basically the META table uses a custom comparator that is composed of the comparators for
each Table.

Any advice before I start digging deeper? Are there many places where we assume that row keys
are lexocographiclly sorted?

> Allow to specify a user supplied row key comparator for a table 
> ----------------------------------------------------------------
>
>                 Key: HBASE-661
>                 URL: https://issues.apache.org/jira/browse/HBASE-661
>             Project: Hadoop HBase
>          Issue Type: New Feature
>          Components: client, master, regionserver
>    Affects Versions: 0.2.0
>            Reporter: Clint Morgan
>            Assignee: Clint Morgan
>
> Now that row keys are byte arrays, users should be able to specify a comparator at table
creation time.
> My use case for this is to implement secondary indexes. In this case, row keys for the
index tables will be constructed from an optional prefix of the original row key as well as
the content of column that is being indexed. Then the comparator will first compare based
on the key prefix, and break ties by deserializing the column values and using the deserialized
type's compareTo method.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message