lars hofhansl 2012-09-02, 04:03
Matt Corgan 2012-09-02, 06:29
Ted Yu 2012-09-02, 16:04
-Re: RPC KeyValue encoding
Gregory Chanan 2012-09-02, 19:52
If we make the KeyValue wire format flexible enough I think we'll be able
to tackle the KV as an interface work later. Just throwing out some ideas
We could have a byte at the front of each KV serialization format that
gives various options in each bit e.g.
Omits Rows / Omits Family / Omits Qualifier / Omits Timestamp / Omits Value
/ plus some extra bytes for compression options and extensions. Then we
just need to define where the KV gets its field if it is omitted, e.g. from
the previous KV in the RPC that had that field filled in. We sort of have
this with the optional fields already, although I don't recall exactly how
protobuf handles those (we'd probably have to do some small restructuring);
what's new is defining what it means when a field is omitted.
There's some overhead with the above for small KVs, so you could also go
coarser grain, e.g. the Get request/response could have a similar options
All Share Same Row / All Share Same Family / ... / and one of the bits
could turn on the finer grain options above (per KeyValue).
The advantage of this is that all we'd have to get right in 0.96.0 is the
deserialization. The serialization could just send without any of the
options turned on. And we could experiment later with each specific RPC
call what the best options to use are, as well as what storage to actually
use client/server side, which you discuss.
On Sun, Sep 2, 2012 at 9:04 AM, Ted Yu <[EMAIL PROTECTED]> wrote:
> Thanks for the update, Matt.
> w.r.t. Cell class, since it is so fundamental, should it reside in org.
> apache.hadoop.hbase namespace as KeyValue class does ?
> For CellAppender, is compile() equivalent to flushing ?
> Looking forward to your publishing on the reviewboard.
> On Sat, Sep 1, 2012 at 11:29 PM, Matt Corgan <[EMAIL PROTECTED]> wrote:
> > RPC encoding would be really nice since there is sometimes significant
> > traffic that could be reduced many-fold. I have a particular table that
> > scan and stream to a gzipped output file on S3, and i've noticed that
> > the app server's network input is 100Mbps, the gzipped output can be
> > Finishing the PrefixTree has been slow because I've saved a couple tricky
> > issues to the end and am light on time. i'll try to put it on
> > monday despite a known bug. It is built with some of the ideas you
> > in mind, Lars. Take a look at the
> > Cell<
> > >
> > and CellAppender<
> > >
> > classes
> > and their comments. The idea with the CellAppender is to stream cells
> > it and periodically compile()/flush() into a byte which can be saved to
> > an HFile or (eventually) sent over the wire. For example, in
> > HRegion.get(..), the CellAppender would replace the "ArrayList<KeyValue>
> > results" collection.
> > After introducing the Cell interface, the trick to extending the encoded
> > cells up the HBase stack will be to reduce the reliance on stand-alone
> > KeyValues. We'll want things like the Filters and KeyValueHeap to be
> > to operate on reused Cells without materializing them into full
> > That means that something like StoreFileScanner.peek() will not work
> > because the scanner cannot maintain the state of the currrent and next
> > Cells at the same time. See
> > CellCollator<
> > >
> > for
> > a possible replacement for KeyValueHeap. The good news is that this can
> > done in stages without major disruptions to the code base.
> > Looking at PtDataBlockEncoderSeeker<
lars hofhansl 2012-09-02, 21:56
Matt Corgan 2012-09-03, 18:24
lars hofhansl 2012-09-03, 22:17
Matt Corgan 2012-09-03, 23:55
Ramkrishna.S.Vasudevan 2012-09-04, 09:53
Stack 2012-09-04, 21:29
lars hofhansl 2012-09-05, 00:02