[
https://issues.apache.org/jira/browse/HBASE-1234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12680949#action_12680949
]
Erik Holstad commented on HBASE-1234:
-------------------------------------
Looking at the implementation of the KeyValue.java , we are not using any of
the ByteBuffer specific features that
comes with the overhead of that object. Following the discussion on the IRC
I've seen that other people share
the same view.
Would really just want to have the byte[] and an offset to it that would be
passed around, that would mean going
from 56 to 12 B of overhead. Taking into consideration that we need an object
to be able to store in the the cache
if we want to use maps, which seems reasonable, I think that having a smaller
custom object that would include:
ArrayPtr(8B) + offset+length(8B) + object overhead(16B) = 32B is the best way
to go at this point.
> 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.
