Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hbase.apache.org
Received-SPF: pass (nike.apache.org: domain of ryanobjc@gmail.com designates
 209.85.210.169 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CADcMMgGoB0X8Y=2WL4WjkdS7fcugapip6bEk7LWOG00PiRcPtg@mail.gmail.com>
References: 
 <CALte62xd6ibiijM_TzE97G7wCD3fM5gsxrmWjphAEV8THM=sXQ@mail.gmail.com>
	<CA966E73.1EBA%jacek@fb.com>
	<CAOKsKJU8kN3Beo7jn8g5z+BZZXnQ0=zwZQ8ZWKHdFdT+Z+dN7A@mail.gmail.com>
	<CAK+1EbjUvqE_oFTkQwSgy9A8OTS3+eDM930Mk_Ab3WJ9RzQHtg@mail.gmail.com>
	<CAOKsKJUUBs5po9BBG9M+xqi=4i98b1+F7Zt_L61oLgV5vWoxJQ@mail.gmail.com>
	<CAK+1Ebj4ix=EczOOCsEFcWCk7RoekMLwmk-KRptb_RBhUSN1eg@mail.gmail.com>
	<CAOKsKJVNur4U3f3Sa031G0B21fPTUROJB3DfSfbnuhc7J_K5ZA@mail.gmail.com>
	<CAK+1EbhNF3hqRAE2j6H9FyJ9uXCuyVSDEkvQBK0qu2xkvmEAEA@mail.gmail.com>
	<CAOKsKJXN2-M0NPNA4zFUX3OvsYcq_0=a-UxV71YcWXpKZc0T9Q@mail.gmail.com>
	<CADcMMgHbLUDcbH9Nv5=98j4JFY07GqMBmUpw_pzWZF2DEvHUbA@mail.gmail.com>
	<CADcMMgGoB0X8Y=2WL4WjkdS7fcugapip6bEk7LWOG00PiRcPtg@mail.gmail.com>
Date: Mon, 19 Sep 2011 22:41:33 -0700
Message-ID: 
 <CAK+1Ebh49iSFzh+H=cOKGcYWDQkDC4RVS2wfhKjStofgLJ46ew@mail.gmail.com>
Subject: Re: prefix compression implementation
From: Ryan Rawson <ryanobjc@gmail.com>
To: dev@hbase.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

So if the HCell or whatever ends up returning ByteBuffers, then that
plays straight in to scatter/gather NIO calls, and if some of them are
DBB, then so much the merrier.

For example, the thrift stuff takes ByteBuffers when its calling for a
byte sequence.

-ryan

On Mon, Sep 19, 2011 at 10:39 PM, Stack <stack@duboce.net> wrote:
> One other thought is that exposing ByteRange, ByteBuffer, and v1 array
> stuff in Interface seems like you are exposing 'implementation'
> details that perhaps shouldn't show through. =A0I'm guessing its
> unavoidable though if the Interface is to be used in a few different
> contexts: i.e. "v1" has to work if we are to get this new stuff in,
> some srcs will be DBBs, etc.
>
> St.Ack
>
> On Mon, Sep 19, 2011 at 10:33 PM, Stack <stack@duboce.net> wrote:
>> On Mon, Sep 19, 2011 at 3:26 PM, Matt Corgan <mcorgan@hotpads.com> wrote=
:
>>> I don't think the name is all that important, though i thought HCell wa=
s
>>> less clumsy than KeyValue or KeyValueInterface. =A0Take a look at this
>>> interface on github:
>>>
>>> https://github.com/hotpads/hbase-prefix-trie/blob/master/src/org/apache=
/hadoop/hbase/model/HCell.java
>>>
>>> Seems like it should be trivially easy to get KeyValue to implement tha=
t.
>>> =A0Then it provides the right methods to make compareTo methods that wi=
ll work
>>> across different implementations. =A0The implementations of those metho=
ds
>>> might have an if-statement to determine the class of the "other" HCell,=
 and
>>> choose the fastest byte comparison method behind the scenes.
>>>
>>
>> I'd say call it Cell rather than HCell.
>>
>> You have getRowArray rather than getRow which we currently have but I
>> suppose it makes sense since you can then group by suffix.
>>
>> There is a patch lying around that adds a version to KV by using top
>> two bytes of the type byte. =A0If you need me to dig it up, just say
>> (then you might not have to have v1 stuff in your Interface).
>>
>> You might need to add some equals for stuff like same row, cf, and
>> qualifier... but they can come later.
>>
>> The comparator stuff is currently horrid because it depends on
>> context; i.e. whether the KVs are from -ROOT- or .META. or from a
>> userspace table. =A0There are some ideas for having it so only one
>> comparator for all types but thats another issue.
>>
>> St.Ack
>>
>