HBase是一个面向列的分布式NoSQL数据库，它是建立在Hadoop上的开源项目，在数据管理、存储和处理方面具有很高的可伸缩性和可靠性。虽然HBase与关系型数据库（RDBMS）的本质不同，但许多人仍然想知道为什么没有以HBase作为存储引擎的关系型数据库实现。

首先，我们需要了解HBase和RDBMS之间的基本差异。RDBMS是由一组表格组成的传统数据库，其中每个表都包含行和列。这些表通常使用SQL查询语言进行操作。相反，HBase是一个分布式键值存储系统，它使用类似于哈希表的结构来存储数据，并且没有任何预定义的模式或结构。它还使用Java API而不是SQL来操作数据。

考虑到这些基本差异，将HBase用作关系型数据库的存储引擎可能会导致一些问题。以下是几个主要原因：

1. 数据结构：关系型数据库是基于表格的数据结构，支持各种约束条件和规则，例如外键、唯一键、默认值等。相比之下，HBase是基于键值对的数据结构，不支持任何约束条件或规则。因此，要将HBase用作关系型数据库的存储引擎，需要对数据结构进行大量修改和重新设计。

2. 查询：关系型数据库使用SQL查询语言，该语言具有强大的查询和过滤功能。但是，HBase不支持SQL查询语言，而是使用Java API和HBase的特定查询语言来操作数据。这意味着要将HBase用作关系型数据库的存储引擎，必须重新开发查询语言和API。

3. 事务：关系型数据库支持ACID事务，以确保数据的一致性和可靠性。在HBase中，没有内置的事务支持。虽然可以通过编程方式实现事务，但这需要大量工作，并且会影响HBase的性能。

4. 性能：HBase是为了快速访问大量数据而设计的。与之相比，传统的关系型数据库通常更适合小规模数据处理，较少的读写并发。如果将HBase用作关系型数据库的存储引擎，可能会牺牲性能和响应时间。

尽管存在这些问题，也有一些尝试将HBase与关系型数据库结合使用的项目。例如，Apache Phoenix是一个建立在HBase上的开源SQL接口，它可以让用户像使用传统的关系型数据库一样操作HBase中的数据。另外，Google Cloud Spanner和CockroachDB等数据库似乎已经成功地实现了一个类似的解决方案，但它们是基于Google的Spanner论文提出的“全球性事务”模式。

综上所述，尽管HBase在处理大数据量方面具有优势，但由于与传统关系型数据库的本质差异，将其用作存储引擎可能并不是最佳选择。虽然一些项目和产品已经尝试将两者结合起来，但这种方法仍然需要重大的工程投入和改变。因此，在确定数据库技术时，必须考虑到应用程序的特定要求和数据量，并选择最适合的技术和工具来实现业务目标。