elasticsearch 基础认识与优化建议

最近在做一些索引相关的优化测试，顺便记录一下测试以及效果

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数来提