百姓网 Elasticsearch 2.x 升级之路
|
我们的信息特点是,信息描述内容比较多,并且需要对描述内容做全文索引.这样会导致集群的索引大小非常大,需要占用的磁盘和内存也就很多.从上文可知,我们根据业务特点划分了不同的集群,如果每个集群都包含了信息描述内容,索引都会很大,带来成本的提高,也增加了维护难度. 我们业务另外一个特点是,全文索引查询占所有类型查询比例较低,所以一个大的集群可以提供全部全文索引查询,那么另外的集群就可以不需要索引“信息描述内容”,索引就大大的减小了. 3、time: week(N百万级),2 month(N千万级),full(N 亿级)我们还有采用时间来进行区分的集群.基于某些业务对信息新鲜度敏感,所以可以获取一周或二月的信息即可满足需求.大大减少对 Full 类型集群的访问压力,也能提供快速访问. 4、full cluster(N 亿级) && mini Cluster(N千万级)使用时间划分集群后,还有一个好处,我们可以用二月的信息的集群来作为较小集群,让查询优先访问这个集群,当数据满足条件后,就不需要查询 Full 集群；数据不足继续查询 Full 集群.大集群的访问压力进一步降低. 这时,若查询了较小集群,并且需要准确的 Total Count (默认提供一个 Mini 集群10倍的数字),可以进一步使用 Count API (设置 size:0)去访问 Full 集群. 5、full cluster && other small cluster(N千万级/百万级,业务分拆)这里和 4)不同的地方在于,上面使用的是时间划分,而这里是业务划分.这个集群只包含了特定数据的集群(比如二手大类目的二级类目手机),主要看相关查询量是否很大,若是这类查询带来压力较大,就有必要分出去. 6、Cloud Query (Cached Query)我们的一个特点,第一至三页几乎是所有访问的 80% 以上,所以这部分查询我们构造了一个 Cloud Query 池,用于提供快速访问.这个池： 1)使用 DSL 查询,查询方法同 Elasticsearch. 2)初始化数据从 Elasticsearch 获取. 3)保留了几百个左右新鲜数据. 4)不断更新. 5)数据不足,查询指向 Elasticsearh. 6)使用 Redis zset 存储新鲜数据 (Redis Cluster). 为实现上面的功能,我们使用 golang 语言开发一个 Proxy 类型的服务(代号 4Sea). 五、后话：Elasticsearch 5.00、Lucene 6 “磁盘空间少一半；索引时间少一半；”,Merge 时间和 JVM Heap 占用都会减少,索引本身的性能也提升. “查询性能提升25%；IPV6也支持了”. 1、Profile API,可以用来进行查询性能监控和查询优化.不用再对耗时查询两眼一抹黑. 2、翻页利器： Search After.search 接口的一个新实现,使得你可以深度翻页.这个弥补了 scroll 和 search 的不足. 3、Shrink API: 合并 Shards 数,现在不用担心 shard 数字设置不合理,你可以使用这个 API 去合并以减少索引 shards 数量. 4、Reindex,应该是比较令人心动的 API,可惜需要启用 _source. 5、更新数据的 wait_for refresh 特性,可能在某种用户非异步更新时会有好处,让用户(更新接口)等待到更新完成,避免用户得不到数据或者得到老数据. 6、delete_by_query 重回 core !!!但是实现方式优化了. 7、2.x 中 Deprecated 的功能在这个版本大多移除. 还有更多…. 结语：升级 2.x 成功,5.x 还会远吗?看到上面的好处,我想大家都有强烈的升级冲动. 升级工具： 0.90.x /1.x => 2.x https://github.com/elastic/elasticsearch-migration/tree/1.x 2.x => 5.0 https://github.com/elastic/elasticsearch-migration/tree/2.x Q&A提问：对比下 Elasticsearch 和 Solr?为何贵司选了 ES? 王卫华：当初使用 Solr 的时候,Elasticsearch 还没出现.Elasticsearch 作为一个新出现的开源搜索引擎,有许多新特性,我们从 0.x 就开始使用,当初最看好的是它的管理方便,插件多,接口设计好等比较人性化的特性. 提问：线上集群如何进行不停机 reindex 的,这个过程在有数据不断索引的情况下如何保证原有集群数据同新集群数据一致性? 王卫华：Reindex 是一个高耗操作,所以一般情况下,最好不要提供服务,但是如果索引比较小,这个操作带来的压力一般.索引大,大量的碎片会带来很大的性能问题.所以我们一般对集群每天进行 optimize(force merge).这样在高峰期可以提供较好的性能. 我们现在因为通过 4Sea 的配置,可以让任何比较清闲的集群承担当前 reindex 索引的查询. 提问：GC 选择 CMS,为何不选择 G1 呢? 王卫华：G1 的性能也很不错.官方目前支持 CMS,认为 G1 在 JDK8 还不算成熟.我们在试验中得出的结论 G1 对比稍差一点,并不落后多少. 不过,如果你设置 heap size 大于 30G,我建议你使用 G1.小于 30G,CMS 比较好. 提问：百姓网的 es 集群是从一开始就切成多个了吗?大体分为几个,为什么如此切分?代理服务器上路由实现是如何进行的? 王卫华：我们一开始也只有一个集群,但是我们对性能有追求,几百毫秒一个查询是不可接受的.随着数据越来越多,有些查询顶不住,需要分而治之.才能提供快速访问(毫秒级别). 切分的原则,我们上面讲了,大致是：routing,时间,业务,是否提供全文索引. 代理服务器对查询进行分析,然后导引到合适的集群,比如 week,month,并提供不同的routing. 提问：请问,32G 的物理内存,慢慢越来越少,是否正常?怎样做这方面优化? 王卫华：32G 的内存,JVM 会使用一部分内存.Lucene(系统缓存)会使用一部分. 越来越少是因为 Lucene 索引使用了内存,还有一些可能是其他文件缓存. 一般处理原则是 JVM + 索引大小 < 物理内存 即可. 提问：为何选 Golang 做 Proxy,不用 Java? 王卫华：主要看中 Golang 的 goroutine 和编码的简单舒适感,第三方工具包也足够多,使用过程中也没有 GC 性能问题(至少我们使用中没有这个问题). 题外：我们从 Go 1.4 直接跳到 Go 1.6,解决一些坑(比如升级后锁变化问题),性能有很大的提升. 提问：怎么应对网络不稳定对集群的影响,特别是集群意外断电,导致 shard 的自动迁移,恢复时间长,从而导致集群不稳定,在 2.x 版本对 shard 的均衡分布和自动迁移有没有相关的更新? 王卫华：网络不稳定的情况下,解决办法就是提高 discovery.zen.ping.timeout 的时间,然而这样提供快速查询就比较伤.所以一个集群中保持一个稳定的网络环境还是很重要的. 要加快恢复时间而网络带宽允许的情况下,可以调整 cluster.routing.allocation 和 recovery 各项参数,增加并发,提高同时恢复的 node 数,提高传输速率. 2.x 对 allocation,recovery 进行了不少优化. 文章出处：高可用架构 （编辑：济源站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
