在 Mapping 里面,将 dynamic 参数设置成 strict 可以拒绝索引包含未知字段的文档。 此条 Tips 由 medcl 贡献。

《腾讯Elasticsearch海量规模背后的内核优化剖析》答疑

Elasticsearch | 作者 howardhuang | 发布于2020年05月09日 | | 阅读数:8093

今天下午的《腾讯Elasticsearch海量规模背后的内核优化剖析》分享 大家反映强烈,由于时间关系,大家的问题没能及时答复,这里集中解答,大家如果还有其它疑问也可以持续提问。感谢大家的关注! 另外腾讯云上有内核增强版的ES服务,包含了我们所有的内核优化项,欢迎大家体验! 团队也在持续招聘,欢迎简历来砸:danielhuang@tencent.com; johngqjiang@tencent.com


[尊重社区原创,转载请保留或注明出处]
本文地址:http://elasticsearch.cn/article/13768


37 个评论

Q: From bimapcloud@gmail.com : 內存不夠, ram:disk 大概是多少?
具体看业务场景,一般1 TB的磁盘数据,需要 2- 5GB 左右的 FST内存开销,这个只是FST的开销(常驻内存),一般FST占用50%左右的堆内内存。如果查询和写入压力稍微大一点,32GB Heap,内存很容易成为瓶颈。
Q:From 一野 : 这个余切函数是怎么推导出来的呢?
A:大家只看到了最终的一个余弦公式:𝑦=〖50∗cos〗⁡〖(𝜋/5∗𝑥)+50〗,下面列一下变换过程:
我们有最原始完整的余弦函数:𝑦=𝐴 cos⁡(𝜔𝑥+𝜑)+𝑘,一个余弦函数的前半个周期刚好是一条平滑向下的曲线,不需要左右平移,所以𝜑=0. 我们要限流的区间是5(80%-85%)所以完整的余弦周期𝑇=10, 前半个周期刚好是5,根据周期公式𝜔=2𝜋/𝑇,其中𝑇=10,那么𝜔=𝜋/5。这样我们得到了 𝑦=𝐴 cos⁡〖𝜋/5〗 𝑥+𝑘。公式里面的 A 和 k 的值,我们根据(𝑥=80, y=100 当内存80%时请求通过率100%),(𝑥=85, y=0 当内存85%时请求通过率0)这两个坐标点计算得来。最终得到上面的𝑦=〖50∗cos〗⁡〖(𝜋/5∗𝑥)+50〗。不同的限流区间阈值,最终的目标公式不同。
感谢黄老师,讲的非常精彩,干货满满
Q:From Vincent Liu : 5分钟不写入这个有什么办法监控么?
A:ES本身就有定期检查不写入分片的机制,主要是用于主动的synced flush,可以参考源码 IndexShard.java 中的 checkIdle 函数实现逻辑。
多谢关注!
Q:From 李俊民 : es 放到 data 目录里的 文档json 没压缩吧?
A:底层 lucene 的数据结构分为多种,行存原始 json 在 store field 中是有压缩的,支持不同的压缩算法,可以配置,默认是LZ4,通过 best_compress 参数可以选择压缩比更高的 deflate,但性能也有些影响。列存的 doc value 有非常类似 RLE 的编码策略压缩,但是做的不完善。我们在内核优化版本里面做了加强。
A:From yangsongbai : esrally官网压测的数据,在内网有吗?
Q:esrally 是一个压测工具,我们可以下载下来自行压测自己的集群,当然官方也有基于 esrally 的 benchmark 持续更新。详细参考:https://elasticsearch-benchmarks.elastic.co/
Q:From weizijun : 官方现在主要是_id没放offheap
A:原生版本基于 MMAP,属于 page cache,这里的硬伤是回收策略不好控制,一个大请求搞不好系统内存回收了,FST 从磁盘加载性能就N倍衰减。
PPT 已上传 https://elasticsearch.cn/slides/259
A:From yangsongbai : 腾讯ES团队,有多少人?
Q:人比较少,就等你来
请问一下,视频有回放吗?谢谢。
稍晚点会有的哈
OK 有了以后提供一下链接哈,感谢感谢。
A:From weizijun : 扩展性优化有相关pr地址吗?
Q:扩展性改动比较大,目前暂时还没有反馈给社区,后续会拆分逐步反馈,可以到腾讯云ES体验功能。
A:From picksun.yang : 腾讯云自带的es,和在腾讯云自己部署es,有啥优劣?
Q:一句话概括就是,自建踩过的坑大概率我们帮大家踩过了,我们没踩过的,公有云上的大量客户可能也帮忙踩过了,我们把这些坑填了。详细一些,腾讯云ES提供内核增强版本,在可用性、性能、成本、扩展性方面相较原生版本都有大幅的优化,可以帮助用户省去很多踩坑填坑的时间,大量的运维管理时间,且云上版本和官方合作有x-pack商业套件,功能更全面。

A:From weizijun : 扩展性优化有相关pr地址吗?
Q:扩展性改动比较大,目前暂时还没有反馈给社区,后续会拆分逐步反馈,可以到腾讯云ES体验功能。

A:600节点,总分片数是多少,业务单一吗?如果不单一怎么隔离,如果master 挂了这个故障域会非常大,原生master 比较稳妥最大能去到分片数和节点数多少
Q:总分片数5-10万左右,主要是监控业务,相对单一,因为腾讯云一个地域的监控数据量实在是太大了。原生版本分片数到3万就差不多了,节点数深度调优500左右基本是极限。腾讯云扩展性内核优化版,可以到百万级分片,千级节点。

A:高并发写入我遇到都是 CPU先到瓶颈,是规模特别大才会出现堆内存不够吗?
Q:单纯的高并发不一定导致堆内内存很大,特别在有我们限流场景优化之后。堆内内存不够主要是数据量比较大,open 的索引量很大,导致所有的 FST 都要加载到内存,限制了数据管理的规模,所以要将堆内较大的内存移到堆外。

A:client 被打爆情况怎么规避,data 没挂,一般高基数聚合的桶非常多情况下容易出现(因为裁剪不了其实也不适合在es 做),使用7.7 就可以避免吗?这种情况只能把业务查询停了,不然有多少个client 就打卦多少个client
Q:分享里面讲的 7.7 版本优化是,对于大结果集聚合查询会实现流式内存检查,在内存打爆之前会拒掉请求,保证节点的安全不至于被大请求打挂。大聚合场景分片较多推荐使用 batch reduce 参数,以及加以 index sorting,composite aggregation 分页(7.6版本后有我们的优化),可以显著改善性能。

A:刚才说1核心配 8gb 磁盘?还是其他单位
Q:配置看具体的业务场景,比较常见的是 16 核 64GB内存,2-5 TB 磁盘。

A:冷热分离后,有必要为冻结索引准备专门的节点吗,感觉数据移来移去消耗了带宽和磁盘io,这部分数据基本不会查询。
Q:理论上冷热分离之后,数据会有从热节点到冷节点的搬迁过程。对于写入速度不高,延时要求不高的业务索引也可以考虑直接落在冷节点避免搬迁。冻结的索引理论上都在冷节点上,这部分数据不会占用内存,如果设置专用的节点,资源利用率除了磁盘其它基本没什么开销,有些浪费。对于过冷的数据如果是在云环境上,建议上冷备,存储成本非常低。

A:对于数据量特别小的索引,你们是设置低数量分片吗?如果有那你们是通过什么管理?节点分组吗?
Q:在7.x版本默认的索引分片数都是1个副本分片,相较以前5个有优化。如果索引数据量特别小看看是否考虑业务合并。在我们扩展性优化的版本上,分片数过多不会产生太多的瓶颈。



A:From iPhone11 : 时序方面,如何具体做的?
Q:腾讯云上有 CTSDB 售卖,这款时序数据库就是基于 ES 实现的,欢迎体验!

A:From Serendo : 请问存储和计算分离是什么场景,和现在有什么区别
Q:腾讯ES的存储与计算分离是基于腾讯自研的共享文件系统 CFS 实现的,通过存储与计算分离可以提升一倍的写入性能,因为底层只写一份,底层存储保证数据本身的安全性,存储成本相较现在降低一倍。


A:From 王 文龙 : 从其他云es迁移到腾讯云es的话,有方案解决公网跨云厂商的通信么?
Q:有的哈,感谢老铁的支持。链接供参考:https://cloud.tencent.com/developer/article/1606495,不够可以私信上面的邮件。
视频回放已出炉:https://v.qq.com/x/page/p0964hbxfnn.html
黄老师,有没有针对集群内慢查请求的监控方案,我自己之前做了个插件来做watch 内部读写请求task的执行时间,只允许固定数量的慢查存在,超过就干掉最早的慢请求
黄老师,非常感谢这么精彩的分享!求教几个数据,我们在用ES做日志存储和分析时,发现写入速率最高能达到8M左右(16U,64G RAM,1T SSD),对于一天TB级的数据就需要100台左右的机器,请问贵司用了多少机器来支撑1天PB级的数据,在这方面有什么优化吗? 此外,和上面同样的问题,热备往冷备迁移是会消耗热备的带宽和资源,这影响到了热备的写入,这方面有什么优化吗?
ES本身提供慢查询日志的功能,可以动态开启,详情可以参考:https://cloud.tencent.com/document/product/845/33137 中通过 API 配置的方法。
1)不知道上面描述的 8M 是什么级别的?节点?集群?这个速度不正常,需要看看瓶颈在哪里,bulk size 是多少,shard 数量是多少,刷新频率是多少等等,结合多方面分析。
2)1 PB 左右是某些单个集群的总存储量,不是一天 1PB 哈。这个总量的规模,大概100-200台之间的热机器,集群大小不一样规模不一样。
3)可以根据热节点的业务负载情况,在业务低峰搬迁,另外可以控制不同业务负载情况搬迁并发和带宽的方式降低影响。
8M/S这是一个单节点性能测试的结果,我们也是100多热机器,按照一个primary,一个replica来算的话一天只能接30T左右的数据。bulk size 8000, shard 500左右, 刷新频率 60s. 瓶颈在CPU已经打满,es master节点堆满了pending task。
黄老师,你好,我有几个问题想问下,谢谢解答:
1.你ppt里面说es没有容灾方案,为什么不通过awareness.zone方式实现跨az部署呢?是这种跨az部署有什么局限性吗?
2.多磁盘策略,如果用逻辑券扩展的方式扩展磁盘,linux自己会均衡写每块磁盘吗?
3.对于冷备的数据,后面再次查询的时候,搜索语法上还能支持倒排索引,以及各种聚合分析语法吗?
4.对于有些比较冷的数据,可能很少会有查询的数据,如果采用close索引的方式来做冷处理,等到查询时再打开,这样方式在生产环境中可取吗?
5.对于es的dsl搜索语法,理解起来有些难度,而官方的sql语法支持的也不够丰富,有些场景也支持不了,有时还有对搜索出来的数据做二次加工的需求,类似于linux的管道命令对数据的再处理,有时还希望能支持可视化的语句,类似splunk的搜索语法,对这种搜索需求腾讯在这块有增强吗?
ES本身的代码,集群太大了肯定不行的.
是的,需要一些优化
1. 多可用区容灾需要考虑的面很多,单纯的借助分片放置是远远不够的,涉及到整个网络、分布式架构的容灾能力:1)跨机房网络架构,VIP RS 剔除策略和实效性。2)单可用区异常影响面,例如读写负载的变化。3)接着第二点就要考虑分片的放置策略,也是问题中提到的可用区、机架感知等。3)多可用区场景ES的可用性问题,包括在多可用区环境下数据节点挂掉,Master节点挂掉,或没挂掉hang死等等。原生版本,如果Master节点hang死,最糟糕的情况,可能导致3分钟左右的服务不可用。4)多可用区数据安全性问题,搜索等安全性要求高的场景备份回档实时性要高。
2. 逻辑卷的方式扩展可以实现每块盘均衡。但是逻辑卷存在两个缺陷:1)软件实现,有额外的转发性能开销且较明显。2)如果一块盘损坏,整个逻辑卷都会受影响,整个ES节点不可用。
3. 这里冷备一般是指把数据通过 snapshot 的机制转存到低成本的对象存储如腾讯云的 COS 上,目前需要做查询,还需要从 COS 恢复回来才能进行分析,冷备一般是数据安全性最后一道屏障。如果对冷数据还需要分析,可以建议放到成本也相对较低的冷节点上,查询不受影响。后续腾讯云ES会提供冷备数据直接查询的能力。
4. 这种方式生产环境可以的,close 可以大幅降低内存消耗,可以关注官方在6.8版本后的索引frozen的策略。
5. 腾讯云 ES 支持两种 SQL 的方式,一种是官方原生的 SQL 接口,还有一个社区版本 SQL 插件,可以对比一下是否能满足场景,目前暂时还没有对这块做优化。
谢谢黄老师的解答,再补充几个问题哈:)
1. 在生产环境中发现,当一个集群的分片数量到达1W多时,新建索引就需要好几秒了,但是写入和查询都还好。想问下当分片数量到达什么数量的时候,会较大程度影响到写入和查询呢?
2. 对于成本优化这块,如果想采用SSD和HDD配合的方式存储,热的数据放在SSD,冷的放到HDD,这样的话是不是一定需要迁移数据,因为迁移数据成本很高,如果集群写入一直比较大,没有固定的空闲段,怎么办呢?
3. 上面提到的frozen策略,还有官方的SQL功能,还有其他很多新功能,都是elastic license了,这个license是商业license,并且有可能受到A国的管制,这块腾讯云ES如何考虑呢?会长期演进一个腾讯的ES版本吗?
老师,我想问个问题,我这边是4台物理机,每台物理机用docker虚拟化4个es节点,一共16节点es集群,并且这4台物理机每台安装3个kafka节点,一共是12个kafka节点集群,然后从kafka集群拉取数据写入es,但是写入速度开始一个小时比较高和稳定,1个小时后,写入速度开始下降,并且入库速率变的很不稳定,这个是什么原因啊?(备注:官方文档上的优化都有配置,比如刷新时间,translog,es版本是5.6.8)
慢查日志只能事后去查看,我是想探测到慢查请求就进行告警,并自定义规则对慢查请求做相应的降级处理,甚至干掉某些危险的请求
考虑写入是否有带id?如果有会涉及到先查询再写入,如果数据量越来越大,性能损耗越来越严重。
1)目前ES创建索引的过程是通过元数据同步、diff 推导的方式进行的,流程中会涉及多次元数据全节点同步,以及分片到节点、节点到分片映射结构的全量遍历,因此当分片数过多(上万)会出现创建流程性能瓶颈。自建集群一般建议控制分片数在一万以下,并可以将索引分散创建。社区版本ES分片数上限在3万左右,腾讯云版本ES经过优化,分片数能达到数十上百万,创建速度一般在5秒以下。
2)搬迁主要影响磁盘的io,一般控制搬迁带宽和并发,不会出现影响很大的场景,例如设定带宽20MB。如果实在觉得搬迁效率太低又不能影响正常读写,可以考虑将索引在热接点上滚动分区放置来区分搬迁节点、读写负载节点。
3)腾讯云长期和elasitc官方合作,license这块暂时不会受到影响,请放心使用哈。
写入是没有id的,是es自动生成的id。可能是段合并影响的么,这边看到iowait过高,是每次提交数据量太小了了,现在提交的是5mb一批次,提交的并发很多,如果加大提交的批量大小,减小并发会有好转吗
byx313

byx313 回复 zhous

不建议跟kfk混部署。kfk是会吃掉很多的page cache,在es的写入也很迟page cache,会导致两个混抢。
zhous

zhous 回复 byx313

嗯,现在也在考虑分开安装
byx313

byx313 回复 zhous

官方推荐是5~15mb/batch,看反馈的iowait高,应该是落盘太频繁了。可以试试把refresh_interval调大一点,如果查询不频繁,可以把index buffer的比例调大。
黄老师,您好,请教,如果hot索引读写都会非常频繁,而且对查询时延要求也比较高,有没有好的实施建议?谢谢
目前想到的是采用类似“双buffer”机制做读写分离,在集群里创建2个相同的hot索引A和B,定义两个Alias:readIndex和writeIndex
1)readIndex指向A,writeIndex指向B
2)查询时从readIndex(A)查询,写入往writeIndex(B)。
3)当写入到达一定的量或者到设定周期(比如几分钟),将writeIndex指向A,readIndex指向B,同时将之前写入B的数据同步到A中
利用这样的机制实现读写分离,来应对读写都会非常频繁的索引。

黄老师有没有更好的建议,多谢
黄老师,您好,你在第2点说的,“索引在热节点上滚动分区放置”是什么意思?谢谢
团队也在持续招聘,欢迎简历来砸:danielhuang@tencent.com; johngqjiang@tencent.com

要回复文章请先登录注册