hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HBASE-1234) Change HBase StoreKey format
Date Wed, 04 Mar 2009 05:41:56 GMT

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

stack commented on HBASE-1234:
------------------------------

Chatting w/ lads at HUG6 -- in particular jgray, holstad, jimk, ryan, travis -- we came up
w/ following proposed format:

{code}<int1><int2><int3><row><columnfamily><columnqualifier><timestamp><type>{code}

int1 is the length of row,  2 bytes
int2 is length of columnfamily, 1 byte
int3 is length of columnqualifier, 2 bytes

The ints above are plain ints, not vints

The type is a single byte.  Types are update, cell delete, column delete, column family delete,
row delete and possibly counter.

 

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


Mime
View raw message