On Sun, Jul 28, 2013 at 4:01 PM, Stack <st...@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. - 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. -- Best regards, - Andy Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)
