Hermes与开源的Solr、ElasticSearch的不同

5d6d网

　　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条记录.