HBase的缺陷有哪些？

查询能力弱：提供高效的单行随机查询以及范围扫描，复杂的组合条件查询必须使用Scan+Filter 的方式，稍不注意就是全表扫描，效率极低。HBase 的Phoenix 提供了二级索引来优化查询，但和MySQL 的二级索引一样，只有符合最左匹配的查询条件才能做索引优化，可被优化的查询条件非常有限。  数据派生能力弱：前面章节提到CDC 技术是支撑数据派生体系的核心技术，HBase 不具备CDC 技术。HBase Replication 具备CDC 的能力，但是仅为HBase 内部主备间的数据同步机制。有一些开源组件利用其内置Replication 能力来尝试扩展HBase 的 CDC 技术，例如用于和Solr 同步的Lily Indexer，但是比较可惜的是这类组件从理论和机制上分析就没法做到CDC 技术所要求的数据保序、最终一致性保证等核心需求。  成本高：前面提到结构化大数据存储的关键需求之一是存储与计算的成本分离，HBase 的成本取决于计算所需CPU 核数成本以及磁盘的存储成本，基于固定配比物理资源的部署模式下CPU 和存储永远会有一个无法降低的最小比例关系。即随着存储空间的增大，CPU 核数成本也会相应变大，而不是按实际所需计算资源来计算成本。要达到完全的存储与计算成本分离，只有云上的Serverless 服务模式才能做到。  运维复杂：HBase 是标准的Hadoop 组件，最核心依赖是Zookeeper 和HDFS，没有专业的运维团队几乎无法运维。 热点处理能力差：HBase 的表的分区是Range Partition 的方式，相比Hash Partition 的模式最大的缺陷就是会存在严重的热点问题。HBase 提供了大量的最佳实践文档来指引开发者在做表的Rowkey 设计的时候避免热点，例如采用hash key，或者是salted-table 的方式。但这两种方式下能保证数据的分散均匀，但是无法保证数据访问的热度均匀。访问热度取决于业务，需要一种能根据热度来对Region 进行Split 或Move 等负载均衡的自动化机制。

答复内容摘自《玩转 Tablestore 入门与实战》，这本电子书收录开发者藏经阁 下载连接：https://developer.aliyun.com/topic/download?id=7983