hbase和es在搜索场景的应用，hbasees场景

hbase和es在搜索场景的应用，hbasees场景

背景

    最近有个简单的需求，离线数据挖掘得出的标签需要支持online的查询，查询场景比较简单，支持按照单个id或者多个id批量查询，tp99需要在200ms，批量的时候id 集合的大小不会超过1000，平均下来不会超过200的样子。这种场景直接上ES相对来说比较省事，不过ES占用资源较多，想尝试用hbase来解决这种场景，下面记录下具体的过程。

     为何要考虑HBase?

    为何要用hbase呢？离线数据是存放在hive表里面的，虽然hbase导入hbase和es都挺方便的，不过据我们测试的情况看，hive2hbase采用bulkload 的方式会快些，而且比较简单。导入es的过程中步骤繁琐，需要设置刷新时间和副本数，设置段合并和别名之类的操作，相对来说麻烦许多。hbase按照 rowkey查询的性能还行，单次查询在10+ms左右，虽然支持索引，不过性能差强人意，暂时不准备利用其自身的索引。 只利用hbase来存储元信息，这些信息相对来说比较占空间，仅支持按照 rowkey来查找。

     HBase的若干问题

    丢不掉的ES

    在对hbase进行测试之后，id超过200之后，hbase性能直线下降，很难符合线上的要求了，只能再转回ES了。事实上，在使用hbase之前，我们设想是通过es+hbase或者es+tair来进行对比，这两种场景因为对索引和数据进行了拆分，性能很难和直接利用es进行查询相比，最后转了个圈，还是回到ES上面了，索引信息存储在es里面，由于es存储的信息极其简单，2.5亿的记录索引，经过优化存储，只占用了9G的空间，200个id查询的 rt 也就30ms左右，性能还是比较稳定的。ES的优点如下：

    ES的问题

         一般做系统方案的时候，还是需要根据具体业务场景来区分，复杂不一定好，皮实耐用才是真道理，根据具体场景来做优化，有时候也能收到意想不到的效果。