Mailing-List: contact hadoop-commits-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hadoop-dev@lucene.apache.org
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Apache Wiki <wikidiffs@apache.org>
To: hadoop-commits@lucene.apache.org
Date: Mon, 30 Apr 2007 06:56:49 -0000
Message-ID: <20070430065649.10448.64025@eos.apache.org>
Subject: [Lucene-hadoop Wiki] Trivial Update of "Hbase/HbaseArchitecture" by
 JimKellerman

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Lucene-hadoop Wiki" for change notification.

The following page has been changed by JimKellerman:
http://wiki.apache.org/lucene-hadoop/Hbase/HbaseArchitecture

------------------------------------------------------------------------------
  Other related features and TODOs:
   1. Single-machine log reconstruction works great, but distributed log recovery is not yet implemented. This is relatively easy, involving just a sort of the log entries, placing the shards into the right DFS directories
   1. Data compression is not yet implemented, but there is an obvious place to do so in the HStore.
-  1. We need easy interfaces to !MapReduce jobs, so they can scan tables. We have been contacted by several parties interested in contributing to HBase, and one has signed up to work on the map/reduce interface.
+  1. We need easy interfaces to !MapReduce jobs, so they can scan tables. We have been contacted by Vuk Ercegovac [[mailto(vercego AT SPAMFREE us DOT ibm DOT com)]] of IBM Almaden Research who expressed an interest in working on an HBase interface to the Hadoop map/reduce interface to HBase.
   1. The HMemcache lookup structure is relatively inefficient
   1. File compaction is relatively slow; we should have a more conservative algorithm for deciding when to apply compaction.
   1. For the getFull() operation, use of Bloom filters would speed things up