今天下午的《腾讯Elasticsearch海量规模背后的内核优化剖析》分享 大家反映强烈，由于时间关系，大家的问题没能及时答复，这里集中解答，大家如果还有其它疑问也可以持续提问。感谢大家的关注！ 另外腾讯云上有内核增强版的ES服务，包含了我们所有的内核优化项，欢迎大家体验！ 团队也在持续招聘，欢迎简历来砸：danielhuang@tencent.com; johngqjiang@tencent.com
[尊重社区原创，转载请保留或注明出处]
本文地址：http://searchkit.cn/article/13768
本文地址：http://searchkit.cn/article/13768
37 个评论
Q： From bimapcloud@gmail.com : 內存不夠， ram：disk 大概是多少？
具体看业务场景，一般1 TB的磁盘数据，需要 2- 5GB 左右的 FST内存开销，这个只是FST的开销（常驻内存），一般FST占用50%左右的堆内内存。如果查询和写入压力稍微大一点，32GB Heap，内存很容易成为瓶颈。
具体看业务场景，一般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〗。不同的限流区间阈值，最终的目标公式不同。
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 函数实现逻辑。
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：底层 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：esrally 是一个压测工具，我们可以下载下来自行压测自己的集群，当然官方也有基于 esrally 的 benchmark 持续更新。详细参考：https://elasticsearch-benchmarks.elastic.co/
Q：From weizijun : 官方现在主要是_id没放offheap
A：原生版本基于 MMAP，属于 page cache，这里的硬伤是回收策略不好控制，一个大请求搞不好系统内存回收了，FST 从磁盘加载性能就N倍衰减。
A：原生版本基于 MMAP，属于 page cache，这里的硬伤是回收策略不好控制，一个大请求搞不好系统内存回收了，FST 从磁盘加载性能就N倍衰减。
PPT 已上传 https://elasticsearch.cn/slides/259
A：From yangsongbai : 腾讯ES团队，有多少人？
Q：人比较少，就等你来
Q：人比较少，就等你来
请问一下，视频有回放吗？谢谢。
稍晚点会有的哈
OK 有了以后提供一下链接哈，感谢感谢。
A：From weizijun : 扩展性优化有相关pr地址吗？
Q：扩展性改动比较大，目前暂时还没有反馈给社区，后续会拆分逐步反馈，可以到腾讯云ES体验功能。
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，不够可以私信上面的邮件。
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级的数据，在这方面有什么优化吗？ 此外，和上面同样的问题，热备往冷备迁移是会消耗热备的带宽和资源，这影响到了热备的写入，这方面有什么优化吗？
howardhuang 回复 Judge
ES本身提供慢查询日志的功能，可以动态开启，详情可以参考：https://cloud.tencent.com/document/product/845/33137 中通过 API 配置的方法。
1）不知道上面描述的 8M 是什么级别的？节点？集群？这个速度不正常，需要看看瓶颈在哪里，bulk size 是多少，shard 数量是多少，刷新频率是多少等等，结合多方面分析。
2）1 PB 左右是某些单个集群的总存储量，不是一天 1PB 哈。这个总量的规模，大概100-200台之间的热机器，集群大小不一样规模不一样。
3）可以根据热节点的业务负载情况，在业务低峰搬迁，另外可以控制不同业务负载情况搬迁并发和带宽的方式降低影响。
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的搜索语法，对这种搜索需求腾讯在这块有增强吗？
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 插件，可以对比一下是否能满足场景，目前暂时还没有对这块做优化。
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版本吗？
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）
Judge 回复 howardhuang
慢查日志只能事后去查看，我是想探测到慢查请求就进行告警，并自定义规则对慢查请求做相应的降级处理，甚至干掉某些危险的请求
howardhuang 回复 zhous
考虑写入是否有带id？如果有会涉及到先查询再写入，如果数据量越来越大，性能损耗越来越严重。
1）目前ES创建索引的过程是通过元数据同步、diff 推导的方式进行的，流程中会涉及多次元数据全节点同步，以及分片到节点、节点到分片映射结构的全量遍历，因此当分片数过多（上万）会出现创建流程性能瓶颈。自建集群一般建议控制分片数在一万以下，并可以将索引分散创建。社区版本ES分片数上限在3万左右，腾讯云版本ES经过优化，分片数能达到数十上百万，创建速度一般在5秒以下。
2）搬迁主要影响磁盘的io，一般控制搬迁带宽和并发，不会出现影响很大的场景，例如设定带宽20MB。如果实在觉得搬迁效率太低又不能影响正常读写，可以考虑将索引在热接点上滚动分区放置来区分搬迁节点、读写负载节点。
3）腾讯云长期和elasitc官方合作，license这块暂时不会受到影响，请放心使用哈。
2）搬迁主要影响磁盘的io，一般控制搬迁带宽和并发，不会出现影响很大的场景，例如设定带宽20MB。如果实在觉得搬迁效率太低又不能影响正常读写，可以考虑将索引在热接点上滚动分区放置来区分搬迁节点、读写负载节点。
3）腾讯云长期和elasitc官方合作，license这块暂时不会受到影响，请放心使用哈。
zhous 回复 howardhuang
写入是没有id的，是es自动生成的id。可能是段合并影响的么，这边看到iowait过高，是每次提交数据量太小了了，现在提交的是5mb一批次，提交的并发很多，如果加大提交的批量大小，减小并发会有好转吗
官方推荐是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中
利用这样的机制实现读写分离，来应对读写都会非常频繁的索引。
黄老师有没有更好的建议，多谢
目前想到的是采用类似“双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中
利用这样的机制实现读写分离，来应对读写都会非常频繁的索引。
黄老师有没有更好的建议，多谢
czgbc 回复 howardhuang
黄老师，您好，你在第2点说的，“索引在热节点上滚动分区放置”是什么意思？谢谢
团队也在持续招聘，欢迎简历来砸：danielhuang@tencent.com; johngqjiang@tencent.com
