hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Holstad <erikhols...@gmail.com>
Subject Re: [jira] Commented: (HBASE-1234) Change HBase StoreKey format
Date Tue, 24 Mar 2009 04:46:47 GMT
Thinking about it some more, but mostly using the current format in action I
have found
that the current structure with the type last in the key is nice cause it
only takes one read
from the KeyValue to get to the type, which is sometimes the first thing you
want to check.

On Sat, Mar 21, 2009 at 9:21 AM, Erik Holstad (JIRA) <jira@apache.org>wrote:

>    [
> https://issues.apache.org/jira/browse/HBASE-1234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12688054#action_12688054]
> Erik Holstad commented on HBASE-1234:
> -------------------------------------
> Hey Stack!
> Just want to ask how much work it would be to change the format to
> r/f/type/col/ts? Since it seems to be the best way to use it over at the
> server.
> I also want to let you know how we are going to use KeyValue in the new get
> implementations. We are most likely only going to use the standard
> byte comparator from Bytes and some constructors to create KeyValue, so no
> fancy gets and stuff are needed over at this end.
> > Change HBase StoreKey format
> > ----------------------------
> >
> >                 Key: HBASE-1234
> >                 URL: https://issues.apache.org/jira/browse/HBASE-1234
> >             Project: Hadoop HBase
> >          Issue Type: Improvement
> >            Reporter: stack
> >            Assignee: stack
> >             Fix For: 0.20.0
> >
> >         Attachments: 1234-v2.patch, 1234.patch
> >
> >
> > HBASE-859 cleaned up keys removing the need of HRegionInfo being in the
> context comparing keys.  This issue is about changing the format.  Work done
> in HBASE-859 means changes have been localized to HStoreKey, in particular
> to comparators and parse routines.  We should do this now since 0.20.0 will
> require rewriting all data.
> > Things to consider:
> > <row> <columnfamily> <columnqualifier> <timestamp> <keytype>
> > Or leave off columnfamily altogether and just write it once into the
> hfile metadata (All key compares are done in the Store context so
> columnfamily can be safely left out of the equation; its only when the key
> rises above Store that the columnfamily needs appending).
> > keytype is probably a byte. Types are delete cell, delete row, delete
> family, delete column?  What else?  Where should we put it?  At the end?
>  How should type sort?  Or should it not be part of sort so its just the
> order at which we encounter the key?
> > How are we going to support keys that go in out of chronological order?
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message