HBASE 是否有任何替代方案，特别是在关键范围扫描方面？答案

【问题标题】：Are there any alternatives to HBASE in particular with regards to key range scans?HBASE 是否有任何替代方案，特别是在关键范围扫描方面？
【发布时间】：2025-12-26 08:45:12
【问题描述】：

我欣赏 HBASE 中最相关的功能是键范围扫描，您可以将您的键组合在较高级别的键和较低级别的键下，这使您可以获取与较高级别的键相关的数据层次结构。

例如：

CUSTOMER ID = C100
DEPARTMENT ID = D100
USER ID = U100

上面例子的关键是

C100D100U100K01 : "my data for k01"
C100D100U100K02 : "my data for k02"
C100D100U100K03 : "my data for k03"
...

通过上述方法，您可以通过对 C100* 执行范围扫描，或者如果需要更多详细信息，按部门（例如 C100D100U100* 等）获取与您的客户 ID 相关的所有数据。

在 NOSQL 解决方案范围内，在这方面是否有任何 HBASE 替代方案？

【问题讨论】：

标签： nosql hbase

【解决方案1】：

任何分层键值存储都可以工作。*上有一个（简短的）列表：Hierarchical key-value store。

我最了解的是GT.M，您的示例数据可能如下所示：

customer("C100","D100","U100","K01")="my data for k01"
customer("C100","D100","U100","K02")="my data for k02"
customer("C100","D100","U100","K03")="my data for k03"

所以customer("C100") 可以让您访问单个客户的所有数据，customer("C100","D100") 可以让您访问单个客户的单个部门的所有数据，等等。

【讨论】：

关于 GT.M 的好信息，我不知道。不幸的是，它的许可在非 Linux 平台上有点限制。

【解决方案2】：

如果您使用视图（索引），Couchbase 具有类似的功能。您可以在所有键上创建一个视图，并对它们进行范围查询。据我所知，您只能在密钥的末尾而不是开头的通配符，例如：

AAABBBCCCDDD* // yes
*BBBCCCDDDEEE // no
AAA*CCCDDDEEE // no

这是因为它对键进行排序，当您查询时，您会得到一个子范围。但是，您可以通过创建按不同顺序排序的视图来解决此问题。

【讨论】：

【解决方案3】：

Riak 有二级索引，允许通过匹配索引或范围扫描来查询数据。二级索引的结果可以用作 Riak 的 MapReduce 的输入。检查此以获取更多详细信息：riak secondary indexes

【讨论】：