1. Overview
2. 索引 index
- index优化项
3. 检索 search
- search优化项
4. 系统配置优化项
5. 压测 esrally
6. 监控 marvel
7. 注意事项
8. Reference
9. More
先来看看es的整体架构图,上面有多个重要模块,今天主要写在lucene上面的index模块与search模块的优化经历,力求简要写出改变了configuration之后,会给es cluster带来什么样的影响。
上图展示了一个doc index/write请求过来,es为其建立倒排的过程,而index opt.的优化点就主要集中在该posting list building过程,先认识4个组件(heap buff, os cache, transLog, disk),
mapping
禁用不需要的功能_all
,让查询匹配到具体schema,可以降低索引大小index.query.default_field:your_schema_replace_all, _all字段会给search带来方便,但是会增加index时间和index尺寸indices.memory
,es instance的memory buffer大小,buffer满了/一个refresh周期到了会刷到系统缓存,如果refresh足够大,buffer也足够大,与系统缓存的io次数会越小index.translog
.durability,request/async,translog的持久化策略,每个请求都flush/异步flush,flush持久化策略如下,segment merge
,每次refresh/flush都会产生段,lucene会将小段合并至大段,refresh_interval
,es instance的memory buffer到系统缓存的时间间隔(检索实时性),一次es refresh会产生一个lucene segment;久刷新更能够利用缓存number_of_replicas
,首次索引设置为0,index过程中,如果有副本的话,doc也会马上同步到副本中去的,同时进行分词索引等,而index之后再传送就是传index后的内容了,不需要再经历分词索引部分。首次索引完成后再开启,以防node crashnumber_of_shards
,下面几条供参考,auto doc id
,如果手动为es doc设置一个id,那么es在每个write req都要去确认那个id是否存在,这个过程是比较耗时的。而如果使用es的自动生成id,那么es就会跳过这个确认步骤,写入性能会更好。而对于业务中的表id/sku_id,可以将其作为es document的一个field。但是如果表id/sku_id不作为es doc id,在实时更新的时候会引入duplication,这时候就需要去重节点分离
,master,data,ingest预处理节点,coordinatordisk storage
,SSD固态硬盘,机械硬盘, es heavily uses disk(SSDs, RAID 0)入库
时,Rdd的partition 的NodeClient一次操作基本会和大部分节点建立连接。建议事先根据shard规则(_id % shard_num/ routing_id % shard_num),将同一shard的数据事先都repartition到同一个partition。这样一个partition只要和一个Node建立连接。rdd.partitionBy(sku_id/cid3)倾斜index线程
(增加index线程数,那么search线程数就会减少,类似spark的dynamic memory)index bulk request size
,控制好写入批处理的每批大小上图展示了一个query request过来,es对应的检索过程,默认是两阶段,首先是query过程,然后是fetch过程,
读请求
转发到对应的node,此时req会在primary和replica shard中使用round-robin随机轮询算法,从而随机选择一个,让读请求负载均衡,并在每个shard构造(from+size)长的优先队列routing
number_of_shards
,同上number_of_replicas
,同上filter clause
,如果不需要lucene的score,使用filter语句而不用query语句mapping的数据类型
,选取最小的最合适,keyword, byte, short, integer, long, float, doublenested
比parent-child更友善取舍精度
,now -> now/mmax_num_segments
,一个shard的最大segment数量,值越小,查询时所需打开的segment文件就越小,注意限速segment merge(动态写入更新的index推荐使用默认merge策略)more file system cache
,让系统内存尽可能容纳更多的Lucene索引段文件index segment file,那么搜索走内存的可能性就更大,与磁盘的io交互就越少doc模型
的简单化,使用es的基本term/query/agg功能,而复杂的join, nested, parent-child搜索尽量避免es来做,可以将结果取出来之后,在java/spark client里完成这些复杂聚合操作预先index data
,对于一些常用的range查询,可以将range直接作为一个schema,这样可以直接使用term clause,而不需要走agg的range clause,即agg range price -> term price_range冷热数据分离
, node级别的节点分离
,master node与data node分离清除删除文档
,删除文档参与检索过程,但是返回是会过滤掉,所以如果清理了,就不会参与检索了. only_expunge_deletes = truescroll_api
和search_after
一页一页地拉取,而不是随机跳页https://www.elastic.co/guide/en/elasticsearch/reference/5.6/system-config.html
https://segmentfault.com/a/1190000011174694 https://github.com/elastic/rally
使用esrally进行压测,对比优化前后es cluster的性能。
esrally --distribution-version=5.0.0 --track=geopoint --challenge=append-fast-with-conflicts --car="16gheap"
esrally list pipeline
主要通过es的plugin来监控_cat
api的metrics,
使用marvel查看对应的性能指标,
elasticsearch的版本迭代快,在实际部署使用前,最好阅读一遍对应版本的document,并了解其相应configuration。
——END——