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有空间。就能够不断的加入索引，索引规模不在严重受机器的物理内存和物理磁盘的限制。

容灾和数据迁移easy得多。

4. 採用Gaia进行进程管理（腾讯版的Yarn）

数据在HDFS中，集群规模和扩容都是一件非常easy的事情，Gaia在腾讯集群规模已达万台）。

5. 採用多条件组合跳跃减少数据倾斜

假设某个词语存在数据倾斜，则会与其它条件组合进行跳跃合并（參考doclist的skip list资料）。

6. 多级Merger与自己定义分区

7. GC上进行了一些优化

自己进行内存管理，关键地方的内存对象的创建和释放java内部自己控制，降低GC的压力（类似Hbase的Block Buffer Cache）。

不使用WeakHashMap和全局锁，WeakHashMap使用不当easy内存泄露。并且性能太差。

用于分词的相关对象是共用的，降低重复的创建对象和释放对象。

1kb大小的数据，在笔者的环境下，一台机器每秒能处理4~8W条记录.

拓展阅读

大索引技术。大数据的未来