hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stack <st...@duboce.net>
Subject Re: [UPDATE] Finishing up 0.96 --> WAS Re: 0.95 and 0.96 remaining issues
Date Mon, 29 Jul 2013 15:16:40 GMT
On Sun, Jul 28, 2013 at 5:43 PM, Andrew Purtell <apurtell@apache.org> wrote:

> On Sun, Jul 28, 2013 at 4:01 PM, Stack <stack@duboce.net> wrote:
> > I just did a review of tags.  They look like they need a good bit of
> > work yet.
> >
> Yes that patch I put up on RB is the one that was cluster tested and
> profiled. Let me work with Ram about getting the latest up there. We also
> needed to get a sense of what can work. For that, please correct me if I am
> mistaken about any of the following:
>    - An HFileV3 is fine in concept.

In the patch, it looks to me that v3 is not a true new type but just an h2
w/ tags shoehorned in.  Going forward v3 will not be extensible as done.
 It might as well be called h2+tags?

>    - We subclass KeyValue (as TaggedKeyValue) to avoid changing KeyValue's
>    serialization code and to avoid heap size inflation for the no tags
> case.
>    This is fine modulo issues with encapsulation.

>    - Not plumbing tags all the way through to the client as to minimize
>    risk in 0.96 is ok. (And this benefits security as a bonus and is also
> fine
>    for strictly server-side tag use cases.) This ties in to the above as to
>    why a subclass is needed to carry around tags as in memory state, like
>    memstoreTS.

>    - Changing the encoders is fine, since they are shared by all HFile
>    implementations. Of course as few changes as possible. Tag specific
> changes
>    there - method signature changes mostly - are currently workable but
> ugly,
>    but we can handle that in another pass by subclassing more HFile
> classes to
>    carry V3 specific state.



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message