hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Purtell <apurt...@apache.org>
Subject Re: [UPDATE] Finishing up 0.96 --> WAS Re: 0.95 and 0.96 remaining issues
Date Tue, 30 Jul 2013 23:53:41 GMT
Thanks, I appreciate you taking the time to do that. I promise I won't make
this a debate but I would like to respond to a couple of points, for your
consideration.

> Showed up very late in the merge window

Yes, for that I apologize, we have our respective timetables and sometimes
they coincide and sometimes the interaction is not optimal. Our focuses
have been different and then an arbitrary line was drawn in the sand. We
would like to work with you here. We have made a few dramatic changes to
our approach already to try and accommodate it.

> * Is not the green field HFileV3, and doesn't have time for a complete
re-do

I think it's better actually if a V3 shares as much code as possible with
the V2 implementation except for what is actually different, copy-on-write
as it were. That said, I may be getting ahead of the latest patch so will
wait.

> * Can easily be done without out downtime
> ** (changing the encoders could be done without needing downtime. meaning
no singularity is required).

Therefore indeed we can split the work into pre and post singularity. I
have not seen the latest patch but the set of pre-singularity change was
small before and will be the same or smaller, and post changes that are
optional and can be rolled into seems fine, to me, for 0.96.x where x > 0,
so there's no conflict here.

I wouldn't broach the subject of 1.0 because that is a premature
discussion, though I probably don't agree with how you have structured it,
at least there is one point of disagreement.

> Will 100% have perf impacts.

To be pedantic, small cluster (granted) benchmarking does not show a 100%
impact. Rather if V2 is used instead of V3 the impact of the changes are
not distinguishable from background platform variability. I agree wider
testing and probably tuning is necessary before production. There will be
other experimental features in 0.96.


On Tue, Jul 30, 2013 at 4:08 PM, Elliott Clark <eclark@apache.org> wrote:

> On Tue, Jul 30, 2013 at 3:29 PM, Andrew Purtell <apurtell@apache.org>
> wrote:
> > Perhaps you can elaborate on the difference you see between HFileV3 and
> > namespaces?
>
> Sure. From my perspective,
>
> Namespaces:
> * arrived earlier in the merge window.
> * Has been run publicly on a large cluster
> * Has had more public reviews.
> * Was re-worked to get closer to a greenfield best implementation
> * Is closer to being merged
> * Is less prone to have unforeseen perf impacts.
> * Is almost impossible to create without needing downtime
> ** (hence it should go in the singularity if possible).
>
>
> HFileV3:
> * Showed up very late in the merge window
> * Still needs revisions
> * Hasn't been put on large clusters publicly.
> * Is not the green field HFileV3, and doesn't have time for a complete
> re-do
> * Can easily be done without out downtime
> ** (changing the encoders could be done without needing downtime.
> meaning no singularity is required).
> * Will 100% have perf impacts.
>
> None of that actually has anything to do with what I think is a more
> exciting feature.  It's all about stability of the project and trying
> to find a way move us towards the stable and externally explainable
> release cycles that other real databases have.
>
> I'm actually really excited about tagging.  It could allow a lot of
> new and cool features without adding too much core code.
>



-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

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