Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
HBase >> mail # dev >> hbase 0.94.0

>It has to be possible to eventually retire old code. I think we all
>agreed that we won't retire HFile V1 in 0.94.

I agree, I just don't think you should deprecate for the sake of doing it.
 There are quarantining methods to get rarely-used code out of the way and
minimize interference.  Let's talk about an explicit strategy for that.  I
would rather there be some innocuous deprecated code that's present for a
year longer than it's needed, but no one notices.

I think HFile upgrade in particular is more complicated than you think.
We currently have production traffic running with HFileV1.  It has a 5-min
SLA.  We can't afford to take the entire downtime to rewrite 100GB (or
whatever) worth of data.  We need to do this while the cluster is live.
>It is essential for any successful software product to retire old cruft
>at some point or we'll be in backwards compatibility hell. Matt already
>voiced concerns for his trie prefix compression feature. Is it OK to only
>support that for v2?

I think there's a difference between supporting an deprecated feature and
enhancing it.  You shouldn't need to support compression for V1.  You
should just support the functionality that was present in the past.  I
would ask Matt to work with Mikhail, who is also doing prefix compression
for V2.