最近在做一些索引相关的优化测试,顺便记录一下测试以及效果
1:优化mapping 主要包括 doc_values , index , norms , type的keyword和text // 效果明显
doc_values属性 用于把数据序列化到磁盘,使索引结构更紧密
默认为true,binary类型为false
缺点:产生额外磁盘消耗
index 属性 用于是否对数据索引,对于一些没必要的数据不必要进行索引检索
默认都为true
缺点:对与无索引的对象无法使用条件过滤和查询
norms属性
不必要聚合的属性可以设置为false
keyword和text是String的拓展,5X之后使用这两个属性
keyword属性为对数据不建倒排类似以前的String: { "index": "not_analyzed"},text为对数据进行分词倒排
效果:能极大的减少磁盘空间
2 : 禁用 查询中的 _all , 设置合理的shard分片数 ,使用segment段落合并 // 效果明显
_all 默认打开,会把所有字段都在拷贝到这里,增加磁盘使用和影响查询性能
创建索引时添加 "_all":{"enabled":false}
shard
一个Shard就是一个Lucene实例,是一个完整的搜索引擎。
分片数过多会导致检索时打开比较多的文件,多台服务器之间通讯成本加大。
而分片数过少会导至单个分片索引过大,所以检索速度也会慢。
建议单个分片最多存储10G-20G左右的索引数据,每个实例的每个索引分片数建议在1-2个左右,并且尽量集群的所有节点
都分片数一致,不要出现分片数不一样导致的一个实例负载过大,等待合并的时间变长;
shard副本
使用副本的优点:数据备份,提高对大索引的查询效率,建议副本在1-2个左右,过多的副本会延迟合并时间以及磁盘使用率提高,性价比不高
segments
每个分片包含多个segment,每一个segment都是一个倒排索引;在查询的时,会把所有的segment查询结果汇总归并后最为最终的分片查询结果返回; segment越多,加载到内存中的segment越多,占用segment memory越多,查询性能可能就会下降,因此应该合并小的segment,减小segment数,提高检索的segment数来提