背景

? ? 最近有個簡單的需求，離線數據挖掘得出的標簽需要支持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的若干問題

rowkey的設計，這個關系到數據是否分布均勻，一般根據業務場景強相關，我們這個就是按照id來設計的查詢，前期考慮根據id的首個數字來進行劃分，后來發現 region server 存在嚴重的熱點問題，看了下數據才發現，我們的id是子增的，而且id比較大，主要都落到2，3開頭的region里面了，對于自增的id可以采用id%n 的方法來劃分，最終采用n=60，最后看了下分布到每個 regionserver 的數據非常均勻，基本都在410W左右。

預分區可以均衡讀寫壓力，老生常談的問題了

列可以動態增加，對于每行數據不一樣的應用比較適合，為null的列是不會進行存儲的，這一點很靈活

熱點的問題，在均衡了rowkey的設計之后，可以使得訪問請求能均衡的分布到每個region server，不過從壓測的情況看，數據的rt 波動比較大， 因為blockcache 不是表級別的，全局的lru比較容易被踢出來，如果被踢出來的話，需要去讀hfile了。

因為hbase 是按照column family存儲的，其列名是會保存在keyvalue里面的，比較占用空間，可以簡短一點，另外，讀取數據的過程也是按照column family讀取的，涉及到storeFileScanner的切換，效率會有些影響，不過這塊沒有具體測試過，column family不要超過3個，有時候業務字段拆分成不同的column family更為合理，不過對性能的影響需要再深入測試。?

我們的業務場景是所有數據都要輪一遍，所以blockcache對我們沒啥用，從壓測的結果看200 個 id的情況下,tp99在270ms，對staging進行測試，同機房內，qps也就40多，這個結果比較慘。

對線上機器進行了觀察，發現hbase的region server的memory 和heap使用率都挺高的，比ES的機器配置要高很多了，不符合花小錢搞事情的原則。

? ? 丟不掉的ES

在對hbase進行測試之后，id超過200之后，hbase性能直線下降，很難符合線上的要求了，只能再轉回ES了。事實上，在使用hbase之前，我們設想是通過es+hbase或者es+tair來進行對比，這兩種場景因為對索引和數據進行了拆分，性能很難和直接利用es進行查詢相比，最后轉了個圈，還是回到ES上面了，索引信息存儲在es里面，由于es存儲的信息極其簡單，2.5億的記錄索引，經過優化存儲，只占用了9G的空間，200個id查詢的 rt 也就30ms左右，性能還是比較穩定的。ES的優點如下：

es集群還是比較可靠的，性能杠杠的，之前想著節省資源的情況下用用hbase，不過hbase的blockcache 也不小，es雖然是虛機，單臺只有8G，但還是比較穩定的

es可以通過disable source, 只index而不 store，啟用best compress (可以省 1/3 的空間) ?等達到最大利用率

es ?的吞度量還是不錯的，同樣的壓測，qps是hbase的4倍，rt只有hbase的一半不到。

? ? ES的問題

?ES做簡單的查詢還行，不過要小心返回結果可能并不是你所想的，es 為了提升檢索效率，有些地方是用的近似值，用集合查詢的時候，from to 下，會受限制與window size 的大小，有時候返回的結果不穩定而且不全，這個測試的時候發現了，還是比較坑的。

filter方式因為不計算score和存在緩存的方式，性能一般情況下是ok的，不過據壓測情況看，filter的tp90雖然比query快了大概10ms,但是tp99 的曲線波動的很厲害，遠不如query 的tp99平穩，說明性能是有較大的波動的

?根據2做了些研究，es的cache是基于node級別的，有query和filter的cache，query只緩存count類型的查詢，filter緩存采用lru機制，會根據filter條件做緩存，采用的是bitset，既然是lru，肯定會有換入換出，懷疑是抖動的原因，如果有大牛知道，歡迎指正。

一般做系統方案的時候，還是需要根據具體業務場景來區分，復雜不一定好，皮實耐用才是真道理，根據具體場景來做優化，有時候也能收到意想不到的效果。

總結

以上是生活随笔為你收集整理的hbase和es在搜索场景的应用的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。