为何HBase擅长快速点查询而ClickHouse不适合？原理求解

虽然两者底层都基于LSM类结构，但核心差异来自索引设计逻辑、存储优化方向、数据模型定位三个维度：

1. 索引密度与定位精度的本质区别 #

• ClickHouse的MergeTree采用稀疏主键索引：数据被划分成大尺寸的列存数据块（默认64MB），稀疏索引只存储每个数据块的起始主键值。点查询时，先通过稀疏索引定位到目标数据块，之后必须在整个块内做线性扫描才能找到目标行——这一步是性能瓶颈，尤其是数据块包含几十万行时，扫描成本极高。
• HBase的LSM结构围绕精确行定位优化：内存中的MemStore是有序的RowKey结构，刷盘后的HFile自带两个关键组件：
  • 布隆过滤器：快速排除不包含目标RowKey的HFile，避免无效磁盘IO
  • RowKey范围索引+二级索引：在目标HFile内通过二分查找直接定位到具体行的存储位置，无需全块扫描

2. 存储优化方向的定位差异 #

• ClickHouse是OLAP场景优化的列存引擎，核心目标是批量数据的快速扫描、聚合、分析。大尺寸数据块+稀疏索引的设计，是为了最小化索引存储空间、最大化列存的压缩比和批量扫描效率，天然牺牲了点查询的性能。
• HBase是OLTP场景的键值存储，核心目标就是高效的点查询和小范围RowKey扫描。从MemStore的有序存储到HFile的索引设计，所有优化都围绕"快速定位单个RowKey"展开，布隆过滤器、有序RowKey的二分查找都是为此服务。

3. 主键/RowKey的作用逻辑不同 #

• ClickHouse的主键更多是用于数据排序、去重、分区合并，并非精确行定位的唯一标识（甚至允许主键重复）。稀疏索引只是数据块的"边界标记"，无法直接映射到具体行的位置。
• HBase的RowKey是唯一行标识符，整个存储体系完全基于RowKey的有序性构建：从写入时的排序存储，到查询时的索引定位，所有操作都围绕RowKey的精确匹配设计，这是它点查询高效的核心基础。

内容的提问来源于stack exchange，提问作者Gomo