1、解决 Elasticsearch 分页查询性能瓶颈——从10分钟到秒级的优化实践
https://mp.weixin.qq.com/s/QyyWFim2y6mqhvzmb4FBZw

2、费曼讲解大模型参数微调——小白也能看懂
https://mp.weixin.qq.com/s/39vzs9RTB824oZvF01Kdmw

3、想得久≠答得对！LLM应该自主决定Reasoning长度！
https://mp.weixin.qq.com/s/XTiJrWkuRmyzW5KO3lwrow

4、如何合理规划Elasticsearch的索引｜得物技术
https://mp.weixin.qq.com/s/eKuD4eSF4FS9Fw5xdj6Sow

5、我们为何必须坚持国产替代？
https://mp.weixin.qq.com/s/yliQf4cf1kBfwIG-w_hjTQ

编辑：Muse
更多资讯：http://news.searchkit.cn

前言

ES 7.10 可能是现在比较常见的 ES 版本。但是对于一些相迭代比较慢的早期业务系统来说，ES 6.8 是一个名副其实的“钉子户”。

借着工作内升级调研的任务东风，我整理从 ES 6.8 到 ES 7.10 ELastic 重点列出的新增功能和优化内容。将分为 6 个篇幅给大家详细阐述。

本系列文章主要针对 Elasticsearch 传统的使用功能和基础的模块，像是集群任务的管理、搜索、聚合还有字段类型这样的功能。对于付费功能或者全新的模块，比如：CCR、机器学习和数据流，这里不去深入探讨。

内容的主要来源于 Elastic [各个版本的发布信息](https://www.elastic.co/cn/blog/category/releases)，这里主要比对 ES 6.8 版本到 7.10 版本的差异，并不一一枚举各个新的功能点出现的时间版本。

下面是第一篇：关于 ES 性能的优化

ES 7.10 的性能优化

集群协调算法升级

基于 Elastic 博客提供的资料，Elasticsearch 7.0 的核心改进在于集群协调层的彻底重构，取代了旧版 Zen Discovery 的局限性，引入更健壮、自动化的分布式共识机制。从理论上来说这次优化有着不少的进步，可以显著提升了高可用性与运维效率

主要的优化点有下面三点：

1. 消除分裂脑（Split Brain）风险：通过自动化计算，确保集群状态更新的安全性。旧版 minimum_master_nodes 的手动配置被移除，避免人为误操作。
   
   
2. 提升集群稳定性与恢复速度：节点故障时，集群更快达成一致，减少服务中断窗口。
   
   
3. 简化运维复杂度：可以动态扩缩容无需手动调整配置，系统自动管理选举配置。同时提供更清晰的日志和错误提示，加速故障诊断。
   
   | 旧版配置 | ES 7.0 配置 | 作用 |
   | ------------------------------------ | ---------------------- | ----------------------------------------- |
   | discovery.zen.ping.unicast.hosts | discovery.seed_hosts | 定义初始发现的种子节点列表（IP 或主机名） |
   | discovery.zen.minimum_master_nodes | 已移除 | 由系统自动管理法定人数 |
   
   而在优化的原则里，Elastic 更强调安全第一。比如，在半数以上主节点永久丢失的风险场景下，ES 7.0 之前的集群会静默等待恢复，允许通过启动新空节点强制恢复，这样可能会导致数据不一致或丢失。在 Elasticsearch 7.0 以及更高版本中，这种不安全活动受到了更多限制。集群宁愿保持不可用状态，也不会冒这种风险（除非使用 elasticsearch-node 恢复工具）。
   
   这次优化显著降低了人为错误的风险：移除脆弱的手动配置，减少运维使用的理解成本。同时提升关键业务连续性：快速故障恢复与明确的容错机制，能适合更多场景需求。
   
   当然也并不是尽善尽美的，也会存在大集群下投票节点过多导致竞争激烈而[无法选主的问题](https://mp.weixin.qq.com/s/jU8HCEf2E6hkz_1ZVH_GaQ),这种情况下，建议部署独立的主节点，并且可以考虑适当增大 cluster.election.duration 的配置。
   
   

   Top K 对检索的加速
   

   
   这里的 Top K 主要是指在普通检索时展示前列的数据 Top K。也就是说 Elasticsearch 7.0 对检索数据的查询性能做了明显的改善。那是做了所有查询场景的提升么？
   
   ELastic 做了这么一个场景假设：如果用户通常只关注搜索结果的第一页，且并不关心具体匹配的文档总数，对于超出一定数量的数据搜索引擎可以展示“超过 10,000 条结果”并提供分页浏览来优化搜索效率。但是在实际过程中用户常在查询中使用高频词（如“the”或“a”），这迫使 Elasticsearch 为大量文档计算评分，明显占用了查询资源的使用，即使这些常见词对相关性排序贡献甚微。
   
   
   而现在，Elasticsearch 现在可以跳过那些在早期阶段就被判定为不会进入结果集顶部的低排名记录的评分计算，从而显著提升查询速度。这里主要涉及了 block-max WAND 算法的实现。这是一个复杂且漫长的优化过程，有兴趣的同学可以阅读一下这段[Magic WAND: Faster Retrieval of Top Hits in Elasticsearch](https://www.elastic.co/blog/fa ... x-wand)。
   
   
   从 Elastic 的测试结果来看，新算法的优化让 term 查询加速了 3-7 倍。当然从场景背景可以看出，这个优化主要在大数据量下有明显效果（小数据量也不会有太多的日常高频词）。
   
   

   默认开启 soft-delete 减少 translog
   

   
   从 Elasticsearch 7.4 开始,副本的数据恢复，不再完全依赖 translog 了,而是通过索引的 soft-delete 特性（Elasticsearch 7.0 起所有新索引默认启用软删除 soft-deletes）。这样就可以缩小 translog 的使用场景，从而 translog 的保留大小也可以减少了。
   
   那原来使用 translog 是什么样的呢？
   
   translog 是 ES 用于保证数据安全性的重要工具。同时副分片进行恢复时，它也起着重要作用，只要副分片待获取的差异数据是在 translog 所保留的数据范围内，就可以只从 trasnlog 复制差异的部分数据，而不用拖取整个分片。在之前的版本中，Elasticsearch 默认会保留 512M 或 12 小时的 translog 用于副本恢复。
   
   那现在使用的 soft-delete 是什么呢？
   
   soft-deletes 是 Lucene 中实现的特性。这个软删除有时候会和 lucene 本身的标记删除概念发生混淆。为了方便理解，我们在这里归纳一下，lucene 实现删除的方式是一种标记删除的方式，而这种标记删除可以分为硬删除和软删除。软删除和硬删除有一个明显的区分点是：硬删除，被删除的文档对应的文档号用索引文件 .liv 来描述。软删除 soft-delete，被标记为删除的文档不使用索引文件.liv 来描述，而是通过索引文件 .dvd .dvm 来描述。
   
   这里再扩展一下，.liv 文件主要实现 fixedbitset 数据结构。而 .dvd .dvm 则组合实现了 docvalue 这种正排数据结构。
   
   正排索引的数据结构助力了 translog 的‘减负’，副本可以相对简便的通过软删除中的数据标记来实现数据恢复的处理。
   
   
   
   相比较简洁高效的位图索引，docvalue 虽然实现了更多的功能，满足更多的场景，也会带来更多的问题。最明显的就是对于 update 操作，会导致 refresh 变得慢，有些压力场景下 refresh 会达到 10s 以上。
   
   

   数值/日期排序查询加速
   

   
   Elasticsearch 7.6 版本提升了按日期或数值（即任何存储为有符号 64 位整数（long 类型）的字段）进行排序的查询性能。
   
   这背后的优化原理和之前 top K 使用的 Block-Max WAND 算法有点相似，都是利用算法跳过非竞争性文档来实现加速。
   
   实际效果可能因环境而异，受多种参数影响。在 Elastic 进行的测试场景下，可以达到 35 倍的速度优化。
   
   

   FST 内存使用迁移到堆外
   

   
   Elastic 7.3 版本实现了这个优化，是藏在 release note 里的彩蛋。
   
   

   Also mmap terms index (.tip) files for hybridfs #43150 (issue: #42838)
   
   看似不经意的一行，但是带来效果却不小。FST 从堆内转移到堆外后，JVM 的空间可以空余出很客观的一部分。
   
   
   一直以来，ES 堆中常驻内存中占据比重最大是 FST，即 tip(terms index) 文件占据的空间，1TB 索引大约占用 2GB 或者更多的内存，因此为了节点稳定运行，业界通常认为一个节点 open 的索引不超过 5TB。现在，从 ES 7.3 版本开始，将 tip 文件修改为通过 mmap 的方式加载，这使 FST 占据的内存从堆内转移到了堆外由操作系统的 pagecache 管理。
   
   

   存储字段压缩优化
   

   
   Elasticsearch 7.10 基于 Apache Lucene 8.7 引入了对存储字段（stored fields）的更高压缩率优化。不管是对于基于 DEFLATE 的 index.codec: best_compression 还是基于 LZ4 的index.codec: default都有不错的表现，在 Elastic 的测试场景下，最大可达到 10%的存储空间减少。
   
   对于数据压缩 lucene 这次主要做了两个优化。
   
   

4. Elastic 研究发现在存储数据的时候，底层的 block 越大，压缩效果越好，因为中间被压缩的重复数据可能越多。但是大块的 block 也可能因为解码重复数据降低查询速度。
   
   
5. block 间通过共享字典来维持检索效率和数据压缩之间的平衡。
   
   2.1. 首先为压缩算法提供一个数据字典，它也可以用于字符串重复数据删除。如果在要压缩的数据流和字典之间有许多重复的字符串，那么最终可以得到更好的压缩比。在解压缩时也通过字典来快速补足。
   
   
   2.2. 同时，ES 使用更大的数据块，这些数据块本身被分成一个字典和 10 个子块，这些子块使用这个字典进行压缩。
   
   
   而对于实际业务场景中，日志和监控数据的重复率往往会很好，因此在这两个场景中的压缩效果也是最明显的。
   
   

   小结
   

   
   当然，除了这几项外，ES 在各个版本中也做了不少优化，比如：调整 search.max_buckets 增加到 65534；Date histogram 聚合性能优化等等。有兴趣的同学可以参照各个版本的 [release highlight](https://www.elastic.co/guide/e ... s.html)
   
   参考资料：
   
   

6. [Save space and money with improved storage efficiency in Elasticsearch 7.10](https://www.elastic.co/blog/sa ... h-7-10)
   
7. [Elasticsearch 7.3 的 offheap 原理](https://mp.weixin.qq.com/s/QviC_9ElknSS9kxXSMjjbg)
   
8. [Elasticsearch 7.4 的 soft-deletes 是个什么鬼](https://mp.weixin.qq.com/s/_l8JAtqK_NOSP8b7OqSVDg)
   
   

   推荐阅读
   

   
   

   • [谈谈 ES 6.8 到 7.10 的功能变迁（2）- 字段类型篇](https://infinilabs.cn/blog/202 ... part-2)
     
   • [谈谈 ES 6.8 到 7.10 的功能变迁（3）- 查询方法篇](https://infinilabs.cn/blog/202 ... part-3)
     
   • [谈谈 ES 6.8 到 7.10 的功能变迁（4）- 聚合功能篇](https://infinilabs.cn/blog/202 ... part-4)
     
   • [谈谈 ES 6.8 到 7.10 的功能变迁（5）- 任务和集群管理](https://infinilabs.cn/blog/202 ... part-5)
     
   • [谈谈 ES 6.8 到 7.10 的功能变迁（6）- 其他](https://infinilabs.cn/blog/202 ... part-6)
     
     
     

     作者：金多安，极限科技（INFINI Labs）搜索运维专家，Elastic 认证专家，搜索客社区日报责任编辑。一直从事与搜索运维相关的工作，日常会去挖掘 ES / Lucene 方向的搜索技术原理，保持搜索相关技术发展的关注。
     原文：https://infinilabs.cn/blog/202 ... rt-1/
     

1. 我的ES有点强哦（需要梯子）
https://blog.devgenius.io/the- ... 7c791
2. ES索引重建的最佳实践（需要梯子）
https://medium.com/%40mrtkrkrt ... 2ef98
3. 用airflow做ES的索引轮换、snapshot（需要梯子）
https://medium.com/%40MadhavPr ... 240df
https://medium.com/%40MadhavPr ... 65b71
编辑：斯蒂文
更多资讯：http://news.searchkit.cn
 

背景

在处理时序数据时，Rollup 功能通过数据聚合显著降低存储成本，并提升查询性能。Easysearch 与 OpenSearch 均提供了 Rollup 能力，但在多个关键维度上，[Easysearch Rollup](https://infinilabs.cn/blog/202 ... ollup/) 展现出更优的表现。本文将从查询体验、索引管理、聚合能力、性能优化和任务管理五个方面，分析 Easysearch Rollup 相较于 OpenSearch Rollup 的优势。

---

Easysearch vs OpenSearch

1. 查询体验：标准接口与无缝集成

Easysearch Rollup 支持通过标准的 _search API 查询原始索引，系统自动融合 Rollup 数据，用户无需变更现有代码或使用专用查询端点。相比之下，OpenSearch Rollup 虽然使用标准查询语法，但需要用户显式指定 Rollup 索引，无法自动结合原始数据，在需要同时访问原始与聚合数据的场景下显得更为繁琐。

• 差异：Easysearch 支持自动融合原始与 Rollup 数据，OpenSearch 需手动指定索引。
  
• 影响：Easysearch 显著降低了查询逻辑的复杂性和开发维护成本。
  
  ---
  
  

  2. 索引管理：自动化与扩展能力
  

  
  Easysearch Rollup 提供自动索引滚动功能，可通过 rollup.index_max_docs. 配置项为不同的目标 Rollup 索引设置文档数上限，触发新索引的动态创建，显著简化管理流程。此外，配置中支持使用变量（如 {{ctx.source_index}}）动态生成目标索引名，便于多个任务复用同一模板，批量扩展 Rollup 任务时更加高效和灵活。
  
  相比之下，OpenSearch Rollup 依赖 Index State Management（ISM）策略或手动操作进行索引切换，配置复杂、监控成本高，且在大规模任务部署时缺乏灵活的模板化机制。
  
  

• 差异：Easysearch 提供内建的自动滚动机制，OpenSearch 依赖外部策略或手动配置。
  
• 影响：Easysearch 更易于统一管理和大规模扩展，运维成本更低。
  
  ---
  
  

  3. 聚合能力：更广泛的聚合类型支持
  

  
  Easysearch Rollup 支持丰富的聚合类型，包括数值字段的 avg、sum、max、min、percentiles，关键词字段的 terms，日期字段的 date_histogram 与 date_range，还支持 filter 聚合与 special_metrics（可自定义聚合字段和方式）等高级功能。OpenSearch Rollup 支持的聚合类型相对有限，不支持 date_range、filter 等复杂聚合表达式。
  
  

• 差异：Easysearch 提供更全面的聚合能力，OpenSearch 仅支持基础聚合。
  
• 影响：Easysearch 更适合构建复杂的时序分析任务，满足更广泛的业务需求。
  
  ---
  
  

  4. 性能优化：精细化配置与资源控制
  

  
  Easysearch Rollup 提供多种性能优化选项，例如 ROLLUP_SEARCH_MAX_COUNT 控制并发查询数，rollup.hours_before 限制回溯时间范围，write_optimization 和 field_abbr 用于优化写入效率与运行时的内存占用。而 OpenSearch Rollup 缺乏类似的专用配置项，主要依赖通用的集群参数，灵活性与精细度较低。
  
  

• 差异：Easysearch 提供针对 Rollup 场景的专属优化选项，OpenSearch 优化能力较通用。
  
• 影响：Easysearch 在资源使用效率、查询性能和成本控制方面更具优势。
  
  ---
  
  

  5. 任务管理：批量控制与更高灵活性
  

  
  Easysearch Rollup 支持使用通配符进行任务批量管理，且新建任务默认处于非激活状态，用户可按需启用。而 OpenSearch Rollup 中，任务默认立即启用，管理粒度较粗，仅支持单个任务的启停与修改，缺乏批量操作能力。
  
  

• 差异：Easysearch 支持批量任务管理与按需启用，OpenSearch 功能较为基础。
  
• 影响：Easysearch 在多任务环境下提供更高的管理效率和控制能力。
  
  ---
  
  

  实战示例：节点统计 Rollup 配置
  

  
  以下是一个 Easysearch Rollup 任务的配置示例：
  
  json<br /> {<br /> "rollup": {<br /> "source_index": ".infini_metrics",<br /> "target_index": "rollup_node_stats_{{ctx.source_index}}",<br /> "timestamp": "timestamp",<br /> "continuous": true,<br /> "page_size": 200,<br /> "cron": "*/5 1-23 * * *",<br /> "interval": "1m",<br /> "identity": ["metadata.labels.cluster_id", "metadata.labels.node_id"],<br /> "stats": [{ "max": {} }, { "min": {} }, { "value_count": {} }],<br /> "special_metrics": [<br /> {<br /> "source_field": "payload.elasticsearch.node_stats.jvm.mem.heap_used_in_bytes",<br /> "metrics": [{ "avg": {} }, { "max": {} }, { "min": {} }]<br /> }<br /> ],<br /> "write_optimization": true<br /> }<br /> }<br />
  
  

• 亮点：支持自动索引滚动、标准 API 查询、special_metrics 高级聚合与写入优化等特性。
  
  ---
  
  

  总结
  

  
  综合来看，Easysearch Rollup 在以下方面优于 OpenSearch Rollup：
  
  

• 查询接口的兼容性与无感知集成
  
• 自动化的索引管理与扩展能力
  
• 更丰富的聚合类型与表达能力
  
• 针对性更强的性能优化参数
  
• 灵活高效的任务批量管理机制
  
  这些优势使 Easysearch Rollup 更加适用于复杂、多样化的时序数据处理场景，特别是在对性能、扩展性与运维效率有较高要求的系统中表现出色。如果你正在寻找一款功能全面、易于管理的 Rollup 解决方案，Easysearch 是一个值得重点考虑的选择。
  
  

  关于 Easysearch
  

  
  
  
  INFINI Easysearch 是一个分布式的搜索型数据库，实现非结构化数据检索、全文检索、向量检索、地理位置信息查询、组合索引查询、多语种支持、聚合分析等。Easysearch 可以完美替代 Elasticsearch，同时添加和完善多项企业级功能。Easysearch 助您拥有简洁、高效、易用的搜索体验。
  
  官网文档：<https://docs.infinilabs.com/easysearch>;
  
  

  作者：张磊，极限科技（INFINI Labs）搜索引擎研发负责人，对 Elasticsearch 和 Lucene 源码比较熟悉，目前主要负责公司的 Easysearch 产品的研发以及客户服务工作。
  原文：https://infinilabs.cn/blog/202 ... llup/
  

1.OpenSearch与Elasticsearch:一个最新的比较
https://zhuanlan.zhihu.com/p/668706342

2.Elasticsearch BBQ 与 OpenSearch FAISS：向量搜索性能对比
https://blog.csdn.net/UbuntuTo ... 64172

3.Elasticsearch 与 OpenSearch：解开向量搜索性能差距
https://zhuanlan.zhihu.com/p/719251376

编辑：kin122 
更多资讯：http://news.searchkit.cn

1.使用 LlamaIndex、Elasticsearch 和 Mistral 构建 RAG 应用
https://www.elastic.co/search- ... earch
2.使用 Agent、LLM 和 RAG 构建你的第二个大脑 AI 助手
https://github.com/decodingml/ ... ourse
3.我用 Cursor 和 DevBox 业余时间开发了一个 Web 防火墙
https://mp.weixin.qq.com/s/KwhulGZW9mSgA1sti61iZg
4.V0创始人：从设计图到代码，AI绝对能搞定。翻译类的代码任务，都应该交给AI去干
https://mp.weixin.qq.com/s/qQ9Y9pDvxB6xPkdaOGGzDg

编辑：Se7en
更多资讯：http://news.searchkit.cn