海量数据存储与查询的hbase的使用场景浅析以及与elasticsearch搭配的场景

1. 背景

当你的数据量比较多，而且又有要求响应较快的查询场景。你会如何选型？

mysql、mongo、elasticsearch等完全可以，当然，你肯定不会忘了hbase。“海量数据存储”的海量，非hbase莫属。

几种常见数据库的对比如下：

2. hbase应用场景

如果你的查询场景就是根据key拿到结果，没有其它的过滤筛选条件，这就是经典的“点查”，“点查”在hbase上是非常合适的。

当然，除了hbase，还有很多适合“点查”的数据库，比如aws的dynamodb、google的bigtable。但一般公司或自用站点，还是用hbase更合适。

不用很纠结技术选型，hbase依旧非常经典，而且版本也在源源不断的迭代，适合自己的就是最好的。

3. hbase安装依赖

如果你的机器资源不足或只有一两台机器的站点，那么不建议使用hbase，因为它严格依赖hdfs存储系统和hadoop计算架构，以及zookeeper。

如果你的机器配置不高，在安装完这一些，还没安装完hbase的时候，内存就已经被占据了不少了。

4. 场景解析

本篇文章更关注于选型的探讨，不涉及原理的解析。所以当什么场景下应该会使用到hbase，我们再来回顾一下。

hbase的查询方式是通过rowkey做交互。所以，如果你的查询能够抽象为用rowkey直接获取，那么就适合用hbase查询。

这里的rowkey不仅仅是一个id或uuid，它甚至可以是几个字段组成的一个有限长度的字符串，比如“zhangsan-18-beijing”都是可以的。

但是，hbase不能带有其它的filter，比如你要过滤age<18，虽然可以使用hbase的一些协处理器实现，但性能会十分让你惊讶。性能是不好的。

所以，如果你的查询能够抽象为有意义的rowkey，那直接用hbase存储和查询是没有问题的。而且要注意rowkey的长度和散列，太长的rowkey会带来性能的损失，不具备散列特性的rowkey会带来热点问题。

5 自定义过滤下的hbase

从本篇文章的第一小节可以看到，极好的一列出现了三位选手：hbase、redis和elasticsearch

大数据情况下，或海量数据场景下，咱就先让redis休个假吧。如果你的数据较为海量，使用elasticsearch+hbase的搜索存储架构是非常好的选择。

这里引用阿里云的一篇文章：https://developer.aliyun.com/article/941191

6 总结

• 只有点查的场景，你只需要使用hbase。
• 只有搜索的场景，其实你完全可以只使用elasticsearch。
• 但当数据量不断扩大，而且参数搜索的字段可能只是所有字段的一部分，你不妨使用elasticsearch+hbase架构。搜索字段放elasticsearch，需要拿出来数据计算或展示的字段放hbase。各司其职，索引库+存储库分离。

索引库+存储库这个思想也不是为elasticsearch+hbase特定准备的，比如索引库你可以替换为lucene或solr，存储库可以替换为casandra或berkeleydb等都是可以的。任意两个组件都可以组合。