ES——配置详解
集群信息配置
1. 集群名称,默认为elasticsearch:
cluster.name: elasticsearch
2. 节点名称,es启动时会自动创建节点名称,但你也可进行配置:
node.name: "Franz Kafka"
3. 是否作为主节点,每个节点都可以被配置成为主节点,默认值为true:
node.master: true
4. 是否存储数据,即存储索引片段,默认值为true:
node.data: true
master和data同时配置会产生一些奇异的效果:
1) 当master为false,而data为true时,会对该节点产生严重负荷;
2) 当master为true,而data为false时,该节点作为一个协调者;
3) 当master为false,data也为false时,该节点就变成了一个负载均衡器。
你可以通过连接http://localhost:9200/_cluster/health或者http://localhost:9200/_cluster/nodes,或者使用插件http://github.com/lukas-vlcek/bigdesk或http://mobz.github.com/elasticsearch-head来查看集群状态。
5. 每个节点都可以定义一些与之关联的通用属性,用于后期集群进行碎片分配时的过滤:
node.rack: rack314
6. 默认情况下,多个节点可以在同一个安装路径启动,如果你想让你的es只启动一个节点,可以进行如下设置:
node.max_local_storage_nodes: 1
7. 设置一个索引的碎片数量,默认值为5:
集群分片配置
index.number_of_shards: 5
8. 设置一个索引可被复制的数量,默认值为1:
index.number_of_replicas: 1
当你想要禁用公布式时,你可以进行如下设置:
index.number_of_shards: 1
index.number_of_replicas: 0
这两个属性的设置直接影响集群中索引和搜索操作的执行。假设你有足够的机器来持有碎片和复制品,那么可以按如下规则设置这两个值:
1) 拥有更多的碎片可以提升索引执行能力,并允许通过机器分发一个大型的索引;
2) 拥有更多的复制器能够提升搜索执行能力以及集群能力。
对于一个索引来说,number_of_shards只能设置一次,而number_of_replicas可以使用索引更新设置API在任何时候被增加或者减少。
ElasticSearch关注加载均衡、迁移、从节点聚集结果等等。可以尝试多种设计来完成这些功能。
可以连接http://localhost:9200/A/_status来检测索引的状态。
集群交互配置
16. 默认情况下,ElasticSearch使用0.0.0.0地址,并为http传输开启9200-9300端口,为节点到节点的通信开启9300-9400端口,也可以自行设置IP地址:
network.bind_host: 192.168.0.1
17. publish_host设置其他节点连接此节点的地址,如果不设置的话,则自动获取,publish_host的地址必须为真实地址:
network.publish_host: 192.168.0.1
18. bind_host和publish_host可以一起设置:
network.host: 192.168.0.1
19. 可以定制该节点与其他节点交互的端口:
transport.tcp.port: 9300
20. 节点间交互时,可以设置是否压缩,转为为不压缩:
transport.tcp.compress: true
21. 可以为Http传输监听定制端口:
http.port: 9200
22. 设置内容的最大长度:
http.max_content_length: 100mb
23. 禁止HTTP
http.enabled: false
24. 网关允许在所有集群重启后持有集群状态,集群状态的变更都会被保存下来,当第一次启用集群时,可以从网关中读取到状态,默认网关类型(也是推荐的)是local:
gateway.type: local
25. 允许在N个节点启动后恢复过程:
gateway.recover_after_nodes: 1
26. 设置初始化恢复过程的超时时间:
gateway.recover_after_time: 5m
27. 设置该集群中可存在的节点上限:
gateway.expected_nodes: 2
28. 设置一个节点的并发数量,有两种情况,一种是在初始复苏过程中:
cluster.routing.allocation.node_initial_primaries_recoveries: 4
另一种是在添加、删除节点及调整时:
cluster.routing.allocation.node_concurrent_recoveries: 2
29. 设置复苏时的吞吐量,默认情况下是无限的:
indices.recovery.max_size_per_sec: 0
30. 设置从对等节点恢复片段时打开的流的数量上限:
indices.recovery.concurrent_streams: 5
31. 设置一个集群中主节点的数量,当多于三个节点时,该值可在2-4之间:
discovery.zen.minimum_master_nodes: 1
32. 设置ping其他节点时的超时时间,网络比较慢时可将该值设大:
discovery.zen.ping.timeout: 3s
http://elasticsearch.org/guide/reference/modules/discovery/zen.html上有更多关于discovery的设置。
33. 禁止当前节点发现多个集群节点,默认值为true:
discovery.zen.ping.multicast.enabled: false
34. 设置新节点被启动时能够发现的主节点列表(主要用于不同网段机器连接):
discovery.zen.ping.unicast.hosts: ["host1", "host2:port", "host3[portX-portY]"]
35.设置是否可以通过正则或者_all删除或者关闭索引
action.destructive_requires_name 默认false 允许 可设置true不允许
日志和持久化配置
9. 配置文件所在的位置,即elasticsearch.yml和logging.yml所在的位置:
path.conf: /path/to/conf
10. 分配给当前节点的索引数据所在的位置:
path.data: /path/to/data
可以可选择的包含一个以上的位置,使得数据在文件级别跨越位置,这样在创建时就有更多的自由路径,如:
path.data: /path/to/data1,/path/to/data2
11. 临时文件位置:
path.work: /path/to/work
12. 日志文件所在位置:
path.logs: /path/to/logs
13. 插件安装位置:
path.plugins: /path/to/plugins
14. 插件托管位置,若列表中的某一个插件未安装,则节点无法启动:
plugin.mandatory: mapper-attachments,lang-groovy
15. JVM开始交换时,ElasticSearch表现并不好:你需要保障JVM不进行交换,可以将bootstrap.mlockall设置为true禁止交换:
bootstrap.mlockall: true
请确保ES_MIN_MEM和ES_MAX_MEM的值是一样的,并且能够为ElasticSearch分配足够的内在,并为系统操作保留足够的内存。
ES——优化——整体优化
硬件环境选择
如果有条件,尽可能使用SSD硬盘, 不错的CPU。ES的厉害之处在于ES本身的分布式架构以及lucene的特性。IO的提升,会极大改进ES的速度和性能
内存分配
1.当机器内存小于64G时,遵循通用的原则,50%给ES,50%留给lucene。
2.禁止swap,一旦允许内存与磁盘的交换,会引起致命的性能问题。 通过: 在elasticsearch.yml 中 bootstrap.memory_lock: true, 以保持JVM锁定内存,保证ES的性能。
ES——优化——索引优化
ES——docValues
倒排索引满足了关键字搜索的效率,但是对于从另外一个方向的相反操作并不高效,比如聚合(aggregations)、排序(Sorting)和字段的全值查询等时候需要其它的访问模式。
需求开的字段
1,需要聚合的字段,包括sort,agg,group,facet等
2,需要提供函数查询的字段
3,需要高亮的字段,这个确实能加速,但是散仙并不建议把高亮放在服务端程序做,建议放在前端实现,不容易出错而且总体性能比服务端高
4,需要参与自定义评分的字段,这个稍复杂,大多数人的场景中,不一定能用到,后面会单独写一篇文章介绍。
针对字段开启doc_values
ES——Filedata
docValeus只能针对全值匹配建立索引,不会分词后再建立正排索引
ES——特殊操作——滚动查询
数据快照保存:这可以告诉 Elasticsearch 需要保持搜索的上下文环境多久(参考Keeping the search context alive),如 ?scroll=1m
使用上面的请求返回的结果中包含一个 scroll_id,这个 ID 可以被传递给 scroll API 来检索下一个批次的结果
数据快照不变:同时这个查询快照是不会变的,如果后续对文档的改动(索引、更新或者删除)都只会影响后面的搜索请求
基本使用
生成滚动
POST /twitter/tweet/_search?scroll=1m
{
"query": {
"match" : {
"title" : "elasticsearch"
}
}
}
结果返回
{
"_scroll_id": "DnF1ZXJ5VGhlbkZldGNoBQAAAAAAAAABFlV2SjExVXdpUmwtNVFTOThNaWFRTVEAAAAAAAAAAhZVdkoxMVV3aVJsLTVRUzk4TWlhUU1RAAAAAAAAAAMWVXZKMTFVd2lSbC01UVM5OE1pYVFNUQAAAAAAAAAEFlV2SjExVXdpUmwtNVFTOThNaWFRTVEAAAAAAAAABRZVdkoxMVV3aVJsLTVRUzk4TWlhUU1R",
"took": 879,
"timed_out": false,
"_shards": {
"total": 5,
"successful": 5,
"skipped": 0,
"failed": 0
},
"hits": {
"total": 136982,
"max_score": 1,
"hits": [
]
}
}
利用滚动
POST /_search/scroll
{
"scroll" : "1m",
"scroll_id" : "c2Nhbjs2OzM0NDg1ODpzRlBLc0FXNlNyNm5JWUc1"
}
Ps:每次請求都會產生一個 _scroll_id,只有最近的 _scroll_id 才能被使用;如果请求指定了聚合(aggregation),仅仅初始搜索响应才会包含聚合结果。
scroll-scan
扫描室滚动参数,用于避免在深圳分頁中,请求页对于数据打分还有查询顺序的考虑,从而提高性能
POST /twitter/tweet/_search?scroll=1m&search_type=scan
{
"query": {
"match" : {
"title" : "elasticsearch"
}
}
}
扫描式的滚动请求特点:
(1)不算分,关闭排序。结果会按照在索引中出现的顺序返回
(2)不支持聚合
(3)初始 search 请求的响应不会在 hits 数组中包含任何结果。第一批结果就会按照第一个 scroll 请求返回。
(4)参数 size 控制了每个分片上而非每个请求的结果数目,所以 size 为 10 的情况下,如果命中了 5 个分片,那么每个 scroll 请求最多会返回 50 个结果。
(5)如果你想支持打分,即使不进行排序,将 track_scores 设置为 true。
检查 scroll
GET /_nodes/stats/indices/search?pretty
清除 scroll
手动删除滚动查询,避免内存消耗
删除一个
DELETE /_search/scroll
{
"scroll_id" : ["c2Nhbjs2OzM0NDg1ODpzRlBLc0FXNlNyNm5JWUc1"]
}
删除多个
DELETE /_search/scroll
{
"scroll_id" : ["c2Nhbjs2OzM0NDg1ODpzRlBLc0FXNlNyNm5JWUc1", "aGVuRmV0Y2g7NTsxOnkxaDZ"]
}
删除所有
DELETE /_search/scroll/_all
GET参数删除
DELETE /_search/scroll/DXF1ZXJ5QW5kRmV0Y2gBAAAAAAAAAD4WYm9laVYtZndUQlNsdDcwakFMNjU1QQ==,DnF1ZXJ5VGhlbkZldGNoBQAAAAAAAAABFmtSWWRRWUJrU2o2ZExpSGJCVmQxYUEAAAAAAAAAAxZrUllkUVlCa1NqNmRMaUhiQlZkMWFBAAAAAAAAAAIWa1JZZFFZQmtTajZkTGlIYkJWZDFhQQAAAAAAAAAFFmtSWWRRWUJrU2o2ZExpSGJCVmQxYUEAAAAAAAAABBZrUllkUVlCa1NqNmRMaUhiQlZkMWFB
Sliced Scroll
指定一个slice参数,做拆分滚动查询;
max
GET /twitter/_search?scroll=1m
{
"slice": {
"id": 0, ①
"max": 2 ②
},
"query": {
"match" : {
"title" : "elasticsearch"
}
}
}
GET /twitter/_search?scroll=1m
{
"slice": {
"id": 1,
"max": 2
},
"query": {
"match" : {
"title" : "elasticsearch"
}
}
}
ES——特殊操作——重建索引
分片数量一旦确定,所以不可以修改,此时就需要重建索引
简单指令
创建一个new_index,指定好正确的mapping和分片数量即可
POST _reindex
{
"source": {
"index": "old_index"
},
"dest": {
"index": "new_index"
}
}
冲突指令
文档id发生冲突时间,elasticsearch强制性的将文档转储到目标中,覆盖具有相同类型和ID的任何内容
POST _reindex
{
"source": {
"index": "old_index"
},
"dest": {
"index": "new_index",
"version_type": "internal"
}
}
批量指令
需要迁移的数据量过大时,我们会发现reindex的速度会变得很慢,因为重复的网络请求比较多
POST _reindex
{
"source": {
"index": "source",
"size": 5000
},
"dest": {
"index": "dest",
"routing": "=cat"
}
}
配置依据
批量大小取决于数据、分析和集群配置,但一个好的起点是每批处理5-15 MB
1)从大约5-15 MB的大容量开始,慢慢增加,直到你看不到性能的提升。然后开始增加批量写入的并发性(多线程等等)。
2)使用kibana、cerebro或iostat、top和ps等工具监视节点,以查看资源何时开始出现瓶颈。如果您开始接收EsRejectedExecutionException,您的集群就不能再跟上了:至少有一个资源达到了容量。
要么减少并发性,或者提供更多有限的资源(例如从机械硬盘切换到ssd固态硬盘),要么添加更多节点。
分片指令
每个Scroll请求,可以分成多个Slice请求,可以理解为切片,各Slice独立并行
POST _reindex?slices=5&refresh
{
"source": {
"index": "twitter"
},
"dest": {
"index": "new_twitter"
}
}
配置依据
1)slices大小的设置可以手动指定,或者设置slices设置为auto,auto的含义是:针对单索引,slices大小=分片数;针对多索引,slices=分片的最小值。
2)当slices的数量等于索引中的分片数量时,查询性能最高效。slices大小大于分片数,非但不会提升效率,反而会增加开销。
3)如果这个slices数字很大(例如500),建议选择一个较低的数字,因为过大的slices 会影响性能。