Elasticsearch 核心技术与实战
阮一鸣
eBay Pronto 平台技术负责人
66492 人已学习
新⼈⾸单¥68
课程目录
已完结/共 100 讲
第八章:保护你的数据 (3讲)
第十一章:索引生命周期管理 (2讲)
第十二章:用Logstash和Beats构建数据管道 (3讲)
第十三章:用Kibana进行数据可视化分析 (4讲)
实战1:电影搜索服务 (3讲)
实战2:Stackoverflow用户调查问卷分析 (3讲)
备战:Elastic认证 (5讲)
Elasticsearch 核心技术与实战
登录|注册
留言
25
收藏
沉浸
阅读
分享
手机端
回顶部
当前播放: 40 | 分片及其生命周期
00:00 / 00:00
高清
  • 高清
1.0x
  • 2.0x
  • 1.5x
  • 1.25x
  • 1.0x
  • 0.75x
  • 0.5x
网页全屏
全屏
00:00
付费课程,可试看
01 | 课程介绍
02 | 内容综述及学习建议
03 | Elasticsearch简介及其发展历史
04 | Elastic Stack家族成员及其应用场景
05 | Elasticsearch的安装与简单配置
06 | Kibana的安装与界面快速浏览
07 | 在Docker容器中运行Elasticsearch Kibana和Cerebro
08 | Logstash安装与导入数据
09 | 基本概念:索引、文档和REST API
10 | 基本概念:节点、集群、分片及副本
11 | 文档的基本CRUD与批量操作
12 | 倒排索引介绍
13 | 通过Analyzer进行分词
14 | Search API概览
15 | URI Search详解
16 | Request Body与Query DSL简介
17 | Query String&Simple Query String查询
18 | Dynamic Mapping和常见字段类型
19 | 显式Mapping设置与常见参数介绍
20 | 多字段特性及Mapping中配置自定义Analyzer
21 | Index Template和Dynamic Template
22 | Elasticsearch聚合分析简介
23 | 第一部分总结
24 | 基于词项和基于全文的搜索
25 | 结构化搜索
26 | 搜索的相关性算分
27 | Query&Filtering与多字符串多字段查询
28 | 单字符串多字段查询:Dis Max Query
29 | 单字符串多字段查询:Multi Match
30 | 多语言及中文分词与检索
31 | Space Jam,一次全文搜索的实例
32 | 使用Search Template和Index Alias查询
33 | 综合排序:Function Score Query优化算分
34 | Term&Phrase Suggester
35 | 自动补全与基于上下文的提示
36 | 配置跨集群搜索
37 | 集群分布式模型及选主与脑裂问题
38 | 分片与集群的故障转移
39 | 文档分布式存储
40 | 分片及其生命周期
41 | 剖析分布式查询及相关性算分
42 | 排序及Doc Values&Fielddata
43 | 分页与遍历:From, Size, Search After & Scroll API
44 | 处理并发读写操作
45 | Bucket & Metric聚合分析及嵌套聚合
46 | Pipeline聚合分析
47 | 作用范围与排序
48 | 聚合分析的原理及精准度问题
49 | 对象及Nested对象
50 | 文档的父子关系
51 | Update By Query & Reindex API
52 | Ingest Pipeline & Painless Script
53 | Elasticsearch数据建模实例
54 | Elasticsearch数据建模最佳实践
55 | 第二部分总结回顾
56 | 集群身份认证与用户鉴权
57 | 集群内部安全通信
58 | 集群与外部间的安全通信
59 | 常见的集群部署方式
60 | Hot & Warm架构与Shard Filtering
61 | 分片设计及管理
62 | 如何对集群进行容量规划
63 | 在私有云上管理Elasticsearch集群的一些方法
64 | 在公有云上管理与部署Elasticsearch集群
65 | 生产环境常用配置与上线清单
66 | 监控Elasticsearch集群
67 | 诊断集群的潜在问题
68 | 解决集群Yellow与Red的问题
69 | 提升集群写性能
70 | 提升集群读性能
71 | 集群压力测试
72 | 段合并优化及注意事项
73 | 缓存及使用Breaker限制内存使用
74 | 一些运维的相关建议
75 | 使用Shrink与Rollover API有效管理时间序列索引
76 | 索引全生命周期管理及工具介绍
77 | Logstash入门及架构介绍
78 | 利用JDBC插件导入数据到Elasticsearch
79 | Beats介绍
80 | 使用Index Pattern配置数据
81 | 使用Kibana Discover探索数据
82 | 基本可视化组件介绍
83 | 构建Dashboard
84 | 用Monitoring和Alerting监控Elasticsearch集群
85 | 用APM进行程序性能监控
86 | 用机器学习实现时序数据的异常检测(上)
87 | 用机器学习实现时序数据的异常检测(下)
88 | 用ELK进行日志管理
89 | 用Canvas做数据演示
90 | 项目需求分析及架构设计
91 | 将电影数据导入Elasticsearch
92 | 搭建你的电影搜索服务
93 | 需求分析及架构设计
94 | 数据Extract & Enrichment
95 | 构建Insights Dashboard
96 | Elastic认证介绍
97 | 考点梳理
98 | 集群数据备份
99 | 基于Java和Elasticseach构建应用
100 | 结课测试&结束语
登录 后留言

全部留言(25)

  • 最新
  • 精选
Geek_817ea4
l老师我总结了一下,帮忙看看有没有错误之处和遗漏的地方: 1)客户端发起数据写入请求,对你写的这条数据根据_routing规则选择发给哪个Shard。 确认Index Request中是否设置了使用哪个Filed的值作为路由参数, 如果没有设置,则使用Mapping中的配置, 如果mapping中也没有配置,则使用_id作为路由参数,然后通过_routing的Hash值选择出Shard,最后从集群的Meta中找出出该Shard的Primary节点。 2)写入请求到达Shard后,先把数据写入到内存(buffer)中,同时会写入一条日志到translog日志文件中去。 当写入请求到shard后,首先是写Lucene,其实就是创建索引。 索引创建好后并不是马上生成segment,这个时候索引数据还在缓存中,这里的缓存是lucene的缓存,并非Elasticsearch缓存,lucene缓存中的数据是不可被查询的。 3)执行refresh操作:从内存buffer中将数据写入os cache(操作系统的内存),产生一个segment file文件,buffer清空。 写入os cache的同时,建立倒排索引,这时数据就可以供客户端进行访问了。 默认是每隔1秒refresh一次的,所以es是准实时的,因为写入的数据1秒之后才能被看到。 buffer内存占满的时候也会执行refresh操作,buffer默认值是JVM内存的10%。 通过es的restful api或者java api,手动执行一次refresh操作,就是手动将buffer中的数据刷入os cache中,让数据立马就可以被搜索到。 若要优化索引速度, 而不注重实时性, 可以降低刷新频率。 4)translog会每隔5秒或者在一个变更请求完成之后,将translog从缓存刷入磁盘。 translog是存储在os cache中,每个分片有一个,如果节点宕机会有5秒数据丢失,但是性能比较好,最多丢5秒的数据。。 可以将translog设置成每次写操作必须是直接fsync到磁盘,但是性能会差很多。 可以通过配置增加transLog刷磁盘的频率来增加数据可靠性,最小可配置100ms,但不建议这么做,因为这会对性能有非常大的影响。 5)每30分钟或者当tanslog的大小达到512M时候,就会执行commit操作(flush操作),将os cache中所有的数据全以segment file的形式,持久到磁盘上去。 第一步,就是将buffer中现有数据refresh到os cache中去。 清空buffer 然后强行将os cache中所有的数据全都一个一个的通过segmentfile的形式,持久到磁盘上去。 将commit point这个文件更新到磁盘中,每个Shard都有一个提交点(commit point), 其中保存了当前Shard成功写入磁盘的所有segment。 把translog文件删掉清空,再开一个空的translog文件。 flush参数设置: index.translog.flush_threshold_period: index.translog.flush_threshold_size: #控制每收到多少条数据后flush一次 index.translog.flush_threshold_ops: 6)Segment的merge操作: 随着时间,磁盘上的segment越来越多,需要定期进行合并。 Es和Lucene 会自动进行merge操作,合并segment和删除已经删除的文档。 我们可以手动进行merge:POST index/_forcemerge。一般不需要,这是一个比较消耗资源的操作。

作者回复: 非常棒的总结。你是听了课查了文档总结的吗? 当数据从hot移动到warm,官方建议手工执行一下_forcemerge

2019-08-05
17
59
Ryoma
看到这一节的Index Buffer、Transaction log、Merge、Flush、fsync 等莫名觉得很亲切,在 MySQL 及 Redis 中也有类似的名词,目的虽然不尽相同但也有异曲同工之妙,果然技术都是殊途同归。

作者回复: 嗯 👍

2019-09-04
3
9
于曦程
老师,Transaction Log的写入和Flush看上去类似,都是真正落到磁盘上;我的问题是为什么设计这么复杂,引入index buffer,又用Transaction Log保证数据不丢失,直接把索引落到磁盘不更简单吗?

作者回复: tranactionlog 每次落盘,也可以配置成async,异步操作。 refresh默认一秒生成一个segment,你可以修改刷新的时间,这样就是数据被查到的实施性降低了。你也可以在大量数据写入时,暂时将它设置成-1,也就是不自动刷新。 这两个参数,在数据写入时,都是可以做优化的点。缺点就是分别损失了搜索的实时性和数据的安全性。 这样的设计有一定的灵活性和可配置性。直接都做落盘处理,在有些情况下不够灵活

2019-08-08
3
6
氧气🌙 🐟 🌺
1、认真学完您的课程想参加认证考试,还需要学习官方的Elasticsearch Engineer I和Elasticsearch Engineer II吗?Elasticsearch Engineer I和Elasticsearch Engineer II价格很贵。认证考试费400$ 2、配套学习资料除官方的Elasticsearch Reference [7.1]外,老师可以推荐几本书吗?

作者回复: 我觉得先可以吧视频课程都过一下,然后再结合考试的纲要熟悉一下相关的api。其实要真的能把api都通读一下,我觉得不需要再看专门的书了。

2019-08-04
4
zj
倒排索引不可变性,新加文档都要重建整个索引,这个重建索引就是reindex操作?

作者回复: 倒排索引不可变,指的是你无法对原有的进行更新,而是创建新的,把老的暂时标记成删除。 reindex是说mapping发生变化,或者分词器发生变化,对倒排索引进行重建。应该是不同的概念

2019-08-13
2
3
fgdgtz
老师,我刚入门,我想请问一下作为创业公司,怎么更有效的建立自己的词库呢?现在我是是网上下载的词库,但质量不好,自己再编辑

作者回复: 你可以监控用户的搜索条件和实际结果,同时监控用户实际的点击,然后针对这些去做具体的优化,同时在这个过程不断的完善自己的词库

2019-08-07
2
浅qian的痕迹
elastic数据刷新默认是1s,如果业务端对数据的及时性要求比较高,需要怎么优化,原尝试过只要数据有更改就刷新,但是性能比较差

作者回复: 没有一个标准的答案。 刷新时间小于一秒,必然对硬件的要求会更加好。硬件如果不够,那就只能增加硬件投入。 同时,可以考虑对数据的模型进行优化,做更加合理的数据建模和mapping设定

2019-10-13
1
小鱼
老师,您好,请问下ES和lucene在什么情况下会进行merge操作,另外有了ES和lucene自动merge操作,还需要手工执行吗,以及什么场景下需要手工执行?

作者回复: merge一般不需要人为参与,es自动会做。索引从hot迁移到warm,可以人为对索引做一次force merge

2019-08-03
2
1
老师你好,请问合并segments会影响集群吗

作者回复: 一般情况,我们不需要去手工执行force_merge,因为这是一个比较消耗资源的操作。只有在一些特殊的场景,例如把数据从hot节点移动到warm节点后,才会考虑手动执行force merge。

2019-08-03
1
xierongfei
咨询老师一个问题: 我们有业务场景:按月创建索引,文档数量1000W左右,大小10G(3个data节点,每个节点18G内存),平均每天写入30W左右,自定义id,一次写入一条,ssd磁盘。现在就是有个怪问题,就是一到当月最后一周(数据多了)会出现很多大于500ms慢查询(filter过滤,然后聚合统计),抓出其中一个慢查询,分阶段执行:只进行filter过滤查询,30ms以内,查询结果10条以内,但是一旦加上 agg terms, 瞬间就到 500ms以上(10条数据)。晚上11点(基本没有写入的情况下),执行每次都在50ms以内(refresh 间隔是5s)。 观察过threadpool,没有出现queue满和reject的情况。 这个是不是segment有关系呢?我需要强制merge吗?或者有其他排查方向。

作者回复: 按照你的描述,我的理解,数据量增加以后。当数据没有写入,terms 聚合速度很快,一旦有写入,再去查,aggs就比较慢。 你觉得你可以考虑在做terms aggs时,为keyword字段加上eager_global_oridinals =true试试。因为这样有数据写入refresh时,就会创建缓存,使得你的terms aggs性能得到提升。

2019-08-02
1
收起评论