TracyCoder的博客

Elasticsearch 的性能优化没有银弹，它是一个权衡的过程（Trade-off）。硬件与OS是基础，必须达标。写入优化核心在于“批量”和“减少 Commit”。查询优化核心在于“减少扫描范围”和“利用缓存”。架构层面推荐使用冷热分离应对海量时序数据。

ElasticSearch 的并发控制设计是在吞吐量与一致性之间寻找平衡。关于线程池遇到429拒绝时，不要急着改大queue_size。过大的队列会导致严重的内存压力（OOM）和长尾延迟。应优先考虑优化查询语句（慢查询占用线程时间长）、均衡数据分片或扩展集群硬件。Write 线程池关注 CPU 利用率，Merge 线程池关注磁盘 I/O。关于乐观锁在金融、库存、计数等对数据准确性要求极高的场景，必须使用_seq_no。对于日志型、追加型数据，通常不需要使用并发控制。

FieldData 的正确姿势禁忌：尽量不要在text字段上开启。推荐：在 Mapping 中使用多字段（Multi-fields），保留text用于搜索，增加keyword子字段用于聚合和排序。keyword使用 Doc Values（磁盘列式存储），对堆内存压力极小。"raw": {"type": "keyword" // 聚合用这个！Parent Breaker 的设置默认 70% 比较保守。

ElasticSearch 的性能调优不仅仅是 JVM 的调优，更是对操作系统资源利用的调优。“Heap 负责计算与路由，Off-Heap 负责数据读取”，理解这一分工，并利用 G1GC 来平滑内存回收，您就能构建出一个既稳定又高效的搜索集群。

从 Zen Discovery 到 Cluster Coordination 的转变，标志着 Elasticsearch 从一个“易用的搜索引擎”成熟为一个“严谨的分布式数据库”。生产环境建议版本选择：尽量使用 ES 7.10+ 或 8.x 版本，享受更强的共识安全性。节点角色分离：在大型集群中，设置专用的节点（通常 3 个），不存数据，只负责集群协调，避免 GC 导致的假死（False Positive）触发误选主。监控：密切关注和discovery相关的日志，任何选主事件都应引起运维警惕。

Elasticsearch 之所以能处理 PB 级数据并提供近实时的搜索能力，其核心在于其分布式架构设计。对于开发者而言，理解数据如何在集群中分布、如何被路由到特定的节点，是优化查询性能、规划集群容量的基石。分片 (Sharding)与路由 (Routing)，揭开“文档去哪儿了”的谜题。

如果你处理的是短文本（如商品标题），可能希望bbb值大一些（完全归一化）；如果你处理的是长篇技术文档，可能希望降低bbb的影响。"index": {"k1": 1.5,"b": 0.6},"title": {特性词频增长线性/平方根 (无上限)渐进饱和(更符合人类直觉)长度归一化简单倒数可调参数bbb控制参数调优较少k1bk_1, bk1​b灵活可调适用场景短文本、简单场景通用场景，尤其是长短文本混合。

Apache Lucene 的Segment设计是在写入吞吐量、查询延迟和磁盘空间利用率之间做出的精妙平衡。保证了读取的高效和安全。Merge解决了碎片化问题，并承担了物理删除数据的职责。则通过智能分层，防止了合并风暴的发生。

BKD Tree 是K-D-B-tree的变体，结合了k-d tree（空间二分）和B+ tree（块状存储、磁盘友好）的优点。BKD-Tree 之所以难理解，是因为它同时涉及逻辑结构（树）和几何结构（空间划分）。光看文字很难想象它是如何“切分”数据的。逻辑树视图几何空间视图（最核心）和物理存储视图。以一个2维数据（地理位置：经度 X，纬度 Y）为例。假设我们在地图上有 8 个点（文档）。BKD-Tree 的构建过程，实际上就是不断“切蛋糕”的过程。

Apache Lucene 通过DocValues完美补全了倒排索引在分析领域的短板。它采用列式存储，将随机 I/O 转化为顺序 I/O。它利用位打包、GCD、Delta等算法将磁盘占用降到最低。它利用OS Cache，让大数据量的聚合分析在毫秒级完成。理解 DocValues 的底层原理，不仅能帮助我们写出更高效的 DSL，更能让我们在面对海量数据分析架构设计时游刃有余。

FST像一张超浓缩的地图，在内存中瞬间定位到 Term 对应的 Block 指针。读取磁盘上的 Block，利用FOR算法极其紧凑地解压出 Posting List。如果存在 Filter 查询，将利用 CPU 的位运算能力，以纳秒级的速度完成集合的交、并、差操作。正是这些对数据结构极致的压榨和优化，造就了 Lucene 乃至 ElasticSearch 的搜索引擎霸主地位。参考资料。

这个错误是由于 Elasticsearch 的默认分页限制导致的。Elasticsearch 默认只允许查询前 10,000 条记录（from + size <= 10000），而查询请求超出了这个限制（请求了 18,660 条）。Scroll API：适用于需要一次性获取大量数据的场景（如导出）。Search After：适用于实时分页场景，性能更好。在Dev Tools的控制台中，执行以下请求（将。

报错信息：TOO_MANY_REQUESTS disk usage exceeded flood-stage watermark,index has read-only-allow-delete block。

Elasticsearch 的分析过程是将文本数据转换成适合搜索的形式的关键步骤。这一过程主要包括四个阶段：字符过滤、分词、词条过滤和词条索引。描述：用户可以根据需要组合不同的分词器、字符过滤器和词条过滤器来创建自定义分析器。示例。

在 Elasticsearch 中，查询（Query）和过滤器（Filter）是用于检索和筛选数据的重要组成部分。它们虽然都能用来查找文档，但在性能和用法上有所不同。下面详细介绍查询和过滤器的概念以及它们之间的区别。

特性scroll核心逻辑偏移量切片游标前向遍历静态快照批量拉取深度分页支持不支持（无限制无限制实时性高（每次查询最新数据）高（基于实时排序）低（基于快照）内存/网络开销高（随from增大）低（仅获取后续数据）中（快照占用内存）分页方向任意页（前后跳转）仅前向（下一页）仅前向（下一页）典型场景小数据量浅分页大数据量实时分页全量数据离线导出优先选择：适合绝大多数实时分页场景，兼顾性能与灵活性；谨慎使用：仅用于小数据量且分页深度较浅的场景；仅用scroll。

Elasticsearch 7.8及之后版本支持两种定义模板的方式，可简记为普通模板定义方式和组件模板新增/创建方式。PUT _index_template/<template_name> # 模板名称（唯一）"index_patterns": ["logs-*", "metrics-*"], # 匹配的索引名模式（支持通配符）"priority": 100, # 模板优先级（高优先级覆盖低优先级）"template": { # 新索引的配置内容。