[
https://issues.apache.org/jira/browse/HBASE-7320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13878279#comment-13878279
]
Matt Corgan commented on HBASE-7320:
------------------------------------
{quote}If we all agree that is OK to store row, family, qualifier, and value
continuously in ram{quote}Sounds like a step in the right direction. So you
would basically wrap naked byte[]'s in KeyValue objects rather than operating
on them directly?
{quote}but it would not help with prefix tries.{quote}Right. PrefixTreeCell
goes further and breaks out each Cell field into its own primitive value/array.
For example, PrefixTreeCell.getFamilyLength() just returns a value it has
already extracted rather than calling a few methods to calculate the length
each time it's called (like KeyValue).
{quote}as there we'd even want to store partial rows, families, etc{quote}I'm
probably reading too closely here. The PrefixTreeCell has a separate array for
row/family/etc, but a single row/family/etc is not split further into
fragments. (It is while encoded, but the decoder assembles each field into
consecutive bytes.)
> Replace calls to KeyValue.getBuffer with appropropriate calls to getRowArray,
> getFamilyArray(), getQualifierArray, and getValueArray
> ------------------------------------------------------------------------------------------------------------------------------------
>
> Key: HBASE-7320
> URL: https://issues.apache.org/jira/browse/HBASE-7320
> Project: HBase
> Issue Type: Bug
> Reporter: Lars Hofhansl
> Assignee: stack
> Fix For: 0.98.0
>
>
> In many places this is simple task of just replacing the method name.
> There, however, quite a few places where we assume that:
> # the entire KV is backed by a single byte array
> # the KVs key portion is backed by a single byte array
> Some of those can easily be fixed, others will need their own jiras.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
