没有合适的资源?快使用搜索试试~ 我知道了~
Elasticsearch原理和调优
需积分: 10 15 下载量 40 浏览量
2018-03-06
16:49:15
上传
评论
收藏 281KB DOCX 举报
温馨提示
试读
12页
ElasticSearch是一个基于Lucene的搜索服务器。它提供了一个分布式多用户能力的全文搜索引擎,本文档对它的配置及其参数性能调优做了讲解
资源推荐
资源详情
资源评论
Elasticsearch 基础理论和配置调优
重要提醒!本文介绍的参数会显著影响 ES 的运行。在修改 ES 的相关运行参数
时,请确保你已理解参数调整会造成的影响,根据实际问题和集群情况进行调
整!否则可能会导致性能和稳定性下降、甚至数据丢失!
注意:由于 ES 版本问题,本文的 API 可能不适用于所有的版本。ES 各版本的
命令参数可以参考官方文档:https://www.elastic.co/guide/en/elasticsearch/
reference/current/index.html
一、简介
ElasticSearch 是一个基于 Lucene 的搜索服务器。它提供了一个分布式多用户能
力的全文搜索引擎,基于 RESTful web 接口。Elasticsearch 是用 Java 开发的,
并作为 Apache 许可条款下的开放源码发布,是当前流行的企业级搜索引擎。
它不但包括了全文搜索功能,还可以进行以下工作:
分布式实时文件存储,并将每一个字段都编入索引,使其可以被搜索。
实时分析的分布式搜索引擎。
可以扩展到上百台服务器,处理 PB 级别的结构化或非结构化数据。
使用案例:
维基百科使用 Elasticsearch 来进行全文搜做并高亮显示关键词,以及提供
search-as-you-type、did-you-mean 等搜索建议功能。
英国卫报使用 Elasticsearch 来处理访客日志,以便能将公众对不同文章的反应
实时地反馈给各位编辑。
StackOverflow 将全文搜索与地理位置和相关信息进行结合,以提供 more-like-
this 相关问题的展现。
GitHub 使用 Elasticsearch 来检索超过 1300 亿行代码。
每天,Goldman Sachs 使用它来处理 5TB 数据的索引,还有很多投行使用它来
分析股票市场的变动。
二、数据写入过程
Lucene 把每次生成的倒排索引,叫做一个段(segment)。然后另外使用一个
commit 文件,记录索引内所有的 segment。而生成 segment 的数据来源,则是
内存中的 buffer。
1、数据写入 --> 进入 ES 内存 buffer (同时记录到 translog)--> 生成倒排索引分
片(segment)
2、将 buffer 中的 segment 先同步到文件系统缓存中,然后再刷写到磁盘
Elasticsearch 的 flush 操作主要通过以下几个参数控制:
默认设置为:每 30 分钟主动进行一次 flush,或者当 translog 文件大小大于
512MB 时主动触发 flush。
index.translog.flush_threshold_period 每 隔 多 长 时 间 执 行 一 次 flush ( 默 认
30m)
index.translog.flush_threshold_size 当事 务日志 大小 到达 此预设 值, 则执行
flush。(默认 512mb)
index.translog.flush_threshold_ops 当事务日志累积到多少条数据后 flush 一次。
三、segment merge 对写入性能的影响
ES 会不断在后台运行任务,主动将这些零散的 segment 做数据归并,尽量让索
引内只保有少量的,每个都比较大的,segment 文件。这个过程是有独立的线
程来进行的,并不影响新 segment 的产生。
当归并完成,较大的这个 segment 刷到磁盘后,commit 文件做出相应变更,
删除之前几个小 segment,改成新的大 segment。等检索请求都从小 segment
转到大 segment 上以后,删除没用的小 segment。这时候,索引里 segment 数
量就下降了
segment 归并的过程,需要先读取 segment,归并计算,再写一遍 segment,
最后还要保证刷到磁盘。可以说,这是一个非常消耗磁盘 IO 和 CPU 的任务。
所以,ES 提供了对归并线程的限速机制,确保这个任务不会过分影响到其他任
务。
用于控制归并线程的数目,推荐设置为 cpu 核心数的一半。 如果觉得自己磁盘
性能跟不上,可以降低配置,免得 IO 情况瓶颈。
index.merge.scheduler.max_thread_count
归并策略:
归并线程是按照一定的运行策略来挑选 segment 进行归并的。主要有以下几条:
index.merge.policy.floor_segment 默认 2MB,小于这个大小的 segment,优先
被归并。
index.merge.policy.max_merge_at_once 默认一次最多归并 10 个 segment
index.merge.policy.max_merge_at_once_explicit 默认 optimize 时一次最多归并
30 个 segment。
index.merge.policy.max_merged_segment 默 认 5 GB , 大 于 这 个 大 小 的
segment,不用参与归并。optimize 除外。
optimize 接口
既然默认的最大 segment 大小是 5GB。那么一个比较庞大的数据索引,就必然
会有为数不少的 segment 永远存在,这对文件句柄,内存等资源都是极大的浪
费。
但 是 由 于 归 并 任 务 太 消 耗 资 源 , 所 以 一 般 不 太 选 择 加 大
index.merge.policy.max_merged_segment 配置,而是在负载较低的时间段,通
过 optimize 接口,强制归并 segment。
curl -XPOST http://127.0.0.1:9200/logstash-2015-06.10/_optimize?
max_num_segments=1
由于 optimize 线程对资源的消耗比普通的归并线程大得多,所以,绝对不建议
对还在写入数据的热索引执行这个操作。
四、副本分片的存储过程
默认情况下 ES 通过对每个数据的 id 值进行哈希计算,对索引的主分片取余,
就是数据实际应该存储的分片 ID。
由于取余这个计算,完全依赖于分母,所以导致 ES 索引有一个限制,索引的主
分片数,不可以随意修改。因为一旦主分片数不一样,所以数据的存储位置计
算结果都会发生改变,索引数据就完全不可读了。
有副本配置情况下,ES 的写入流程
1、客户端请求发送给 Node1 节点,图中的 Node1 是 Master 节点,实际环境中
剩余11页未读,继续阅读
资源评论
qq_34348748
- 粉丝: 0
- 资源: 1
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功