Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 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.
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB