Hermes與開源的Solr、ElasticSearch的不同

?????????談到Hermes的索引技術，相信很多同學都會想到Solr、ElasticSearch。Solr、ElasticSearch在真可謂是大名鼎鼎，是兩個頂級項目，最近有些同學經常問我，“開源世界有Solr、ElasticSearch為什么還要使用Hermes?”

?????????在回答這個問題之前，大家可以思考一個問題，既然已經有了Oracle、MySQL等數據庫為什么大家還要使用Hadoo[下的Hive、Spark？ Oracle和MySQL也有集群版，也可以分布式，那Hadoop與Hive的出現是不是多余的？

?????????Hermes的出現，并不是為了替代Solr、ES的，就像Hadoop的出現并不是為了干掉Oracle和MySQL一樣。而是為了滿足不同層面的需求。

一、Hermes與Solr,ES定位不同

Solr\ES ：偏重于為小規模的數據提供全文檢索服務；Hermes：則更傾向于為大規模的數據倉庫提供索引支持，為大規模數據倉庫提供即席分析的解決方案，并降低數據倉庫的成本，Hermes數據量更“大”。

???????? Solr、ES的使用特點如下：

1. 源自搜索引擎，側重搜索與全文檢索。

2. 數據規模從幾百萬到千萬不等，數據量過億的集群特別少。

Ps:有可能存在個別系統數據量過億，但這并不是普遍現象（就像Oracle的表里的數據規模有可能超過Hive里一樣，但需要小型機）。

???????? Hermes:的使用特點如下：

1. 一個基于大索引技術的海量數據實時檢索分析平臺。側重數據分析。

2. 數據規模從幾億到萬億不等。最小的表也是千萬級別。

在 騰訊17 臺TS5機器，就可以處理每天450億的數據(每條數據1kb左右)，數據可以保存一個月之久。

二、Hermes與Solr,ES在技術實現上也會有一些區別

???????? Solr、ES在大索引上存在的問題：

1. 一級跳躍表是完全Load在內存中的。

這種方式需要消耗很多內存不說，首次打開索引的加載速度會特別慢.

在Solr\ES中的索引是一直處于打開狀態的，不會頻繁的打開與關閉；

這種模式會制約一臺機器的索引數量與索引規模，通常一臺機器固定負責某個業務的索引。

2. 為了排序，將列的全部值Load到放到內存里。

排序和統計（sum，max，min）的時候，是通過遍歷倒排表，將某一列的全部值都Load到內存里，然后基于內存數據進行統計，即使一次查詢只會用到其中的一條記錄，也會將整列的全部值都Load到內存里,太浪費資源，首次查詢的性能太差。

數據規模受物理內存限制很大，索引規模上千萬后OOM是常事。

3. 索引存儲在本地硬盤，恢復難

一旦機器損壞，數據即使沒有丟失，一個幾T的索引，僅僅數據copy時間就需要好幾個小時才能搞定。

4. 集群規模太小

支持Master/Slave模式，但是跟傳統MySQL數據庫一樣，集群規模并沒有特別大的（百臺以內）。這種模式處理集群規模受限外，每次擴容的數據遷移將是一件非常痛苦的事情，數據遷移時間太久。

5. 數據傾斜問題

倒排檢索即使某個詞語存在數據傾斜，因數據量比較小，也可以將全部的doc list都讀取過來（比如說男、女），這個doc list會占用較大的內存進行Cache，當然在數據規模較小的情況下占用內存不是特別多，查詢命中率很高，會提升檢索速度，但是數據規模上來后，這里的內存問題越來越嚴重。

6. 節點和數據規模受限

Merger Server只能是一個，制約了查詢的節點數量；數據不能進行動態分區，數據規模上來后單個索引太大。

7. 高并發導入的情況下， GC占用CPU太高，多線程并發性能上不去。

AttributeSource使用了WeakHashMap來管理類的實例化，并使用了全局鎖，無論加了多大的線程，導入性能上不去。

AttributeSource與NumbericField,使用了大量的LinkHashMap以及很多無用的對象，導致每一條記錄都要在內存中創建很多無用的對象，造成了JVM要頻繁的回收這些對象，CPU消耗過高。

FieldCacheImpl使用的WeakHashMap有BUG，大數據的情況下有OOM的風險。

單機導入性能在筆者的環境下（1kb的記錄每臺機器想突破2w/s 很難）

Solr與ES小結

并不是說Solr與ES的這種方式不好，在數據規模較小的情況下，Solr的這種處理方式表現優越，并發性能較好，Cache利用率較高，事實證明在生產領域Solr和ES是非常穩定的，并且性能也很卓越；但是在數據規模較大，并且數據在頻繁的實時導入的情況下，就需要進行一些優化。

???????? Hermes在索引上的改進：

1. 索引按需加載

大部分的索引處于關閉狀態，只有真正用到索引才會去打開；一級跳躍表采用按需Load，并不會Load整個跳躍表，用來節省內存和提高打開索引的速度。Hermes經常會根據業務的不同動態的打開不同的索引，關閉那些不經常使用的索引，這樣同樣一臺機器，可以被多種不同的業務所使用，機器利用率高。

2. 排序和統計按需加載

排序和統計并不會使用數據的真實值，而是通過標簽技術將大數據轉換成占用內存很小的數據標簽，占用內存是原先的幾十分之一。

另外不會將這個列的全部值都Load到內存里，而是用到哪些數據Load哪些數據，依然是按需Load。不用了的數據會從內存里移除。

3. 索引存儲在HDFS中

理論上只要HDFS有空間，就可以不斷的添加索引，索引規模不在嚴重受機器的物理內存和物理磁盤的限制。容災和數據遷移容易得多。

4. 采用Gaia進行進程管理（騰訊版的Yarn）

數據在HDFS中，集群規模和擴容都是一件很容易的事情，Gaia在騰訊集群規模已達萬臺）。

5. 采用多條件組合跳躍降低數據傾斜

如果某個詞語存在數據傾斜，則會與其他條件組合進行跳躍合并（參考doclist的skip list資料）。

6. 多級Merger與自定義分區

7. GC上進行了一些優化

自己進行內存管理，關鍵地方的內存對象的創建和釋放java內部自己控制，減少GC的壓力（類似Hbase的Block Buffer Cache）。

不使用WeakHashMap和全局鎖，WeakHashMap使用不當容易內存泄露，而且性能太差。

用于分詞的相關對象是共用的，減少反復的創建對象和釋放對象。

1kb大小的數據，在筆者的環境下，一臺機器每秒能處理4~8W條記錄.

轉載于:https://blog.51cto.com/mengphilip/1622533

總結

以上是生活随笔為你收集整理的Hermes与开源的Solr、ElasticSearch的不同的全部內容，希望文章能夠幫你解決所遇到的問題。

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