hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin Beyer (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HBASE-82) [hbase] VOTE: should row keys be less restrictive than hadoop.io.Text?
Date Tue, 19 Feb 2008 02:40:34 GMT

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

Kevin Beyer commented on HBASE-82:
----------------------------------

Yes, bytes + comparator would work fine for jaql.  Preferably, it would be the same comparators
that are already used by the sort code, which work on serialized bytes (but also on WritableComparables,
so that might be a problem).  If these comparators are inconsistent, then the sort in map/reduce
will not work properly.  I think it is ok to document the transitivity requirement, but I
don't see how you can enforce it in any way.  Different key types are fine, as long as the
comparator knows how to handle them.  If you can't reuse the same comparator interface, I
can always implement my comparisons in another place, but I already have two of them (one
in the WritableComparable, and one in the Comparator).

I don't see how column families and the key comparator are related, except that they are both
table-level metadata. Yes, I agree that a single comparator would be used for the entire table.


> [hbase] VOTE: should row keys be less restrictive than hadoop.io.Text?
> ----------------------------------------------------------------------
>
>                 Key: HBASE-82
>                 URL: https://issues.apache.org/jira/browse/HBASE-82
>             Project: Hadoop HBase
>          Issue Type: Wish
>            Reporter: Jim Kellerman
>
> I have heard from several people that row keys in HBase should be less restricted than
hadoop.io.Text.
> What do you think?
> At the very least, a row key has to be a WritableComparable. This would lead to the most
general case being either hadoop.io.BytesWritable or hbase.io.ImmutableBytesWritable. The
primary difference between these two classes is that hadoop.io.BytesWritable by default allocates
100 bytes and if you do not pay attention to the length, (BytesWritable.getSize()), converting
a String to a BytesWritable and vice versa can become problematic. 
> hbase.io.ImmutableBytesWritable, in contrast only allocates as many bytes as you pass
in and then does not allow the size to be changed.
> If we were to change from Text to a non-text key, my preference would be for ImmutableBytesWritable,
because it has a fixed size once set, and operations like get, etc do not have to something
like System.arrayCopy where you specify the number of bytes to copy.
> Your comments, questions are welcome on this issue. If we receive enough feedback that
Text is too restrictive, we are willing to change it, but we need to hear what would be the
most useful thing to change it to as well.

-- 
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