HBase的领导人探讨Hadoop、BigTable和分布式数据库
但是禁闭（lock-in）问题又来了：一旦你的应用变得流行起来，当你试图将你的应用从App Engine上迁移出来的时候，即便拥有自己的硬件颇具经济意义，你也无法拥有平台（你的系统构建于其上）的所有软件。从很多方面来讲，这看起来是LAMP优点的退步。
这就是说，就算出现了不利于HBase以及用于解析GQL等等一个Google App Engine DataStore API的实现，我们也不能对这一产品说不。
5. M/R范式对于批处理数据应用得很好。在更多的基于事务/单一请求的范式下，Hadoop应用得如何？
MapReduce（不论是Google的还是Hadoop的）是用于处理不适合传统数据库的海量数据的理想技术。但它又不适合事务/单一请求处理。而HBase使用了来自Hadoop核心的HDFS，在其常用操作中并没有使用MapReduce。
但是，HBase支持高效随机存取，因此它可以被用于你的业务的一些事务性元素。你获取一行的性能可能会低于其他方式（比 如说MySQL），但是当你的事务吞吐量增加时你得到了很好的伸缩性。但是你也可以吃到自己的蛋糕，因为HBase获得了来自IBM研究院院一群人的一些 非常好的捐赠，可以很容易将HBase作为MapReduce的源及目的来使用，因此，你基于数据的HBase也可以分享MapReduce的批处理操 作。
6. 使用Hadoop，你们所发现的最好的东西是什么？
作为Hadoop的一个子项目，就像是装上了双引擎。最大的推动力是我们可以借用Hadoop的核心开发者。而且，作为 Hadoop社区的一部分，已经把用户吸引到了HBase上来了。我们利用了Hadoop中已经完成的大量工作——HBase的许多代码是重用 Hadoop的代码。我们也被公布于Hadoop社区，从中获取反馈，这对我们来说是好处是巨大的。
第二个推动力是，我们是Apache的一部分。Apache界有许多已经开发好的程序和基础架构，我们可以直接使用而无需自己开发。
7. 最坏的东西又是什么？
我们只往好处看（笑）。如果非要说点什么……
在许多方面，Hadoop的HDFS和MapReduce开发完全是一回事，因此有时很难让核心开发者理解我们使用HDFS的区别;比如，MapReduce通常不能随即读取，而HBase必须能够做到这一点。
而且在HDFS中缺少append操作（参见HADOOP-1700）。没有这个操作，HBase可能会在服务器崩溃时丢失数据。看起来我们很可能在Hadoop 0.18.0中获得这一特性。
8. 哪些公司正在使用HBase？
Powerset和Rapleaf首当其冲。我们所知的积极使用HBase承载大量数据集的公司包括WorldLingo和Wikia，许多其他的公司正初步涉足HBase。如果还有其他公司对使用HBase感兴趣，就告诉我们吧！
9. HBase未来是如何规划的？
在不久的将来，我们将稳定我们的0.1分支。大约在下周，我们将发布0.1.2。我们知道稳定的供应是发展用户基础和捐助 者的关键方法。另外，在5月份我们的下一个重大发布——0.2中，你将看到对健壮性、大量更好的集群自管理特性如区域再平衡、及客户端API方面有很大的 改进。
查看英文原文：HBase Leads Discuss Hadoop, BigTable and Distributed Databases
延伸阅读：Hypertable项目领导者谈Hadoop和分布式数据库