My understanding, which may be faulty, is the option works until a column is modified and then it fails in a difficult-to-fix manner. The jira hints that the issue could impact how clients, such as ZooKeeper, function as well as HBase.
If this is true, then rather than a "default on" in the next rev, encouraging a development/production distinction in practice may be more productive? Would clear documentation on how to get the considerable performance improvements in production systems be the best short-term solution? I will continue to dig, but coming up to speed on the HBase implementation will take my time short term, can someone comment on the "client issues"? Bruce Williams On 11/23/08, Michael Stack <[EMAIL PROTECTED]> wrote: > Its currently an option in hbase but little excercised (to the best of my > knowledge) and there is currently one issue regards their operation > (https://issues.apache.org/jira/browse/HBASE-922). > > Maybe you can figure the issue? Otherwise, chatting with others, we're > thinking that in next rev. of our store file format, they should just be on > by default. See here for some notes on new file format: > http://wiki.apache.org/hadoop/Hbase/NewFileFormat. > > St.Ack > > > Bruce Williams wrote: > > I just read that Bigtable's use of Bloom Filters for lookup resulted > > in considerable performance improvements. Does Hbase employ any form > > of Bloom filter? > > > > If not, I am willing to look at it. > > > > Bruce Williams > > > > > > > > -- "Discovering...discovering...we will never cease discovering... and the end of all our discovering will be to return to the place where we began and to know it for the first time." -T.S. Eliot
