Hermes與開源的Solr、ElasticSearch的不同
談到Hermes的索引技術，相信很多同學都會想到Solr、ElasticSearch。Solr、ElasticSearch在真可謂是大名鼎鼎，是兩個頂級項目，最近有些同學經常問我，“開源世界有Solr、ElasticSearch為什么還要使用Hermes?”
在回答這個問題之前，大家可以思考一個問題，既然已經有了Oracle、Mysql等數據庫為什么大家還要使用ES下的Hive、Spark？ Oracle和Mysql也有集群版，也可以分布式，那ES與Hive的出現是不是多余的？
Hermes的出現，並不是為了替代Solr、ES的，就像Hadoop的出現並不是為了干掉Oracle和Mysql一樣。而是為了滿足不同層面的需求。
一、Hermes與Solr,ES定位不同
Solr\ES ：偏重於為小規模的數據提供全文檢索服務；Hermes：則更傾向於為大規模的數據倉庫提供索引支持，為大規模數據倉庫提供即席分析的解決方案，並降低數據倉庫的成本，Hermes數據量更“大”。
u Solr、ES的使用特點如下：
1. 源自搜索引擎，側重搜索與全文檢索。
2. 數據規模從幾百萬到千萬不等，數據量過億的集群特別少。
Ps:有可能存在個別系統數據量過億，但這並不是普遍現象（就像Oracle的表里的數據規模有可能超過Hive里一樣，但需要小型機）。
u Hermes:的使用特點如下：
1. 一個基於大索引技術的海量數據實時檢索分析平台。側重數據分析。
2. 數據規模從幾億到萬億不等。最小的表也是千萬級別。
在 騰訊17 台TS5機器，就可以處理每天450億的數據(每條數據1kb左右)，數據可以保存一個月之久。
二、Hermes與Solr,ES在技術實現上也會有一些區別
u 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是非常穩定的，並且性能也很卓越；但是在數據規模較大，並且數據在頻繁的實時導入的情況下，就需要進行一些優化。
u 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條記錄.