Elasticsearch 知识体系手册

本手册基于多 Agent 并行检索 + 主 Agent 汇总生成，涵盖 Elasticsearch 核心概念与架构、索引搜索 API、性能优化、集群管理、生态集成、生产最佳实践六大维度，适用于学习回顾与生产参考。

一、核心概念与架构

1.1 倒排索引底层原理

Elasticsearch 基于 Apache Lucene，每个 shard 就是一个 Lucene 索引。

核心数据结构：

Term Dictionary（term → docFreq + pointer）
       ↓
Posting List（docID, freq, positions）

• Lucene 不存原文，只存每个词出现在哪些文档（docID 列表）+ 词频/位置
• FST（Finite State Transducer）：term dictionary 的存储结构，类似前缀树但更紧凑，内存占用比 HashMap 低 50%+
• Posting List 压缩：Lucene 使用 FOR（Frame of Reference）或 PFOR（Patched FOR）编码，将 docID 列表差分存储，大幅节省空间

Doc Values 列式存储：

• 倒排索引加速搜索，Doc Values 加速排序/聚合
• Doc Values 在索引时构建，按列存储，与倒排互补
• text 类型无 Doc Values，这是 text 不能排序/聚合的根本原因

Segment 机制：

• 每个 shard 的数据由多个 segment 组成，写入新文档时先写内存 buffer，定期生成新 segment（refresh，默认 1s）
• Segment 是不可变的（immutable），删除不物理删除，而是记录一个 del 文件（live docs bitmap）标记删除
• 段合并时物理清理已删除文档，合并成更大段

1.2 分片与副本（Sharding & Replication）

分片策略原则：

• 每个分片建议 10~50 GB 数据
• 分片数过小 → 数据量大时单片过大，查询慢
• 分片数过大 → 过多小 segment，内存压力大
• 计算公式：primary_shards = data_nodes * (1~2)（写入密集场景取上限）

1.3 集群发现与选主（Discovery & Master Election）

• ES 7.x 默认使用 zen2 协议（可切换为 EC2/Azure/GCP 云发现）
• Bootstrap Checks：启动时严格检查各项配置（heap size、memory lock、file descriptors 等）
• minimum_master_nodes：防止脑裂，推荐设为 (master_eligible_nodes / 2) + 1
• 选主流程：PING 探测 → 节点列表排序 → Bully 算法选中最高 node_id

1.4 数据写入流程

写入路径：Client → Coordinating Node → Primary Shard → Replica Shard → Response

1. 请求先到 Coordinating Node，根据 _routing 计算目标 shard
2. 写入 Primary Shard 的 memory buffer + translog（同步追加）
3. Primary 成功后并行转发到所有 Replica Shard
4. 当 translog flush_threshold_size 达到阈值或 sync_interval 到期，触发 lucene commit，生成新 segment

二、索引与搜索 API

2.1 Mapping 配置

{
  "mappings": {
    "dynamic": "strict",
    "properties": {
      "title": {
        "type": "text",
        "analyzer": "ik_max_word",
        "fields": {
          "keyword": { "type": "keyword" }
        }
      },
      "price": { "type": "scaled_float", "scaling_factor": 100 },
      "location": { "type": "geo_point" },
      "tags": { "type": "keyword" },
      "created_at": { "type": "date" }
    }
  }
}

关键配置说明：

2.2 Query DSL 分类

重要原则：bool filter 不计算 score，且会被缓存；bool must 参与评分。优先用 filter 而非 must（除非需要相关性排序）。

2.3 聚合（Aggregations）

实战技巧：

• 查询结果不需要 hits 时设 size: 0，提升性能
• 高基数字段用 composite 聚合做分页，避免深度分页

2.4 Analyze 分析器

分词器由三级组成：Character Filter → Tokenizer → Token Filter

三、性能优化

3.1 JVM Heap 配置

• Heap 大小 ≤ 50% 物理内存，不超过 ~30.5 GB（Compressed OOPs 临界点）
• 配置示例：-Xms31g -Xmx31g（ms 与 mx 必须相同，防止堆调整抖动）
• 禁用 swap：bootstrap.memory_lock: true
• GC 推荐 G1GC：ES 7.x 默认，-XX:MaxGCPauseMillis=200
• 监控指标：node_stats.jvm.mem.heap_used_percent 保持在 75% 以下

3.2 Refresh 与 Translog 调优

• translog.sync_interval：默认 5s，设为更大值可提升写入吞吐
• translog.flush_threshold_size：默认 512MB，触发 Lucene commit

3.3 段合并策略

• 合并策略：TieredMergePolicy（ES 7.x 默认）
• 关键参数：
• index.merge.scheduler.max_thread_count：HDD 或写入密集期设为 1
• index.merge.policy.segments_per_tier：默认 10，越大合并越少、查询越慢

3.4 Filter 缓存机制

• bool filter 查询结果缓存在 Node Query Cache（默认 10% heap）
• 缓存粒度为 segment 级别的 bitset，segment 变更时对应 filter cache 失效
• 提高命中率：多用 filter 代替 must、按时间冷热分离索引减少 segment 变更频率

3.5 Bulk 批量写入

• 推荐大小：5~15 MB 或 5,000~15,000 文档/请求
• 并发控制：写入线程数 ≤ 0 + number_of_shards * 5，超出触发 429 限流
• 写入期间：refresh_interval: -1，写入完成后 POST /_refresh 手动刷新

四、集群管理与安全

4.1 节点类型

生产环境推荐：3 个专用 Master 节点 + 若干 Data 节点 + 若干 Coordinating 节点

4.2 故障转移流程

1. 节点宕机检测（PING 超时，默认 ping_timeout: 3s，ping_retries: 3）
2. Master 触发 副本升级：缺失副本的 Primary 对应 replica 升级为 primary
3. 若有多个副本同时故障，集群状态变为 red
4. 恢复期间写入请求会被拒绝（429），读取仍可在健康副本上执行

4.3 跨集群复制（CCR）

• 原理：Leader index → Follower index（只读），基于 Lucene 索引级别同步
• 适用场景：异地灾备、多数据中心同步

PUT /my-follower/_ccr/follow
{ "remote_cluster": "leader-cluster", "leader_index": "my-index" }

4.4 安全配置（X-Pack Security）

• 认证：支持 Basic / LDAP / PKI / SAML / OIDC
• 通信加密：TLS/SSL 加密集群内部和外部通信
• 角色与权限：基于角色的访问控制（RBAC），可精确到 field / document level

4.5 集群健康与故障排查

常用监控 API：

# 集群健康
GET /_cluster/health?level=indices
# 查看分片未分配原因
GET /_cluster/allocation/explain?pretty
# 节点统计
GET /_nodes/stats

五、与大数据生态集成

5.1 ELK Stack 架构

[数据源] → [Beats/Logstash 采集] → [Elasticsearch 存储索引] → [Kibana 可视化]

5.2 Beats 选型

5.3 与 Spark / Flink 集成

Spark → ES：

spark.write.format("org.elasticsearch.spark.sql")
  .option("es.nodes", "localhost:9200")
  .save("index-name")

• Flink → ES：Flink ES Connector 支持实时流写入
• ES → Spark：通过 es-spark-connector 读取 ES 索引作为 Spark 数据源

六、生产最佳实践

6.1 冷热数据分离架构

Hot Node（SSD）←→ Warm Node（HDD）←→ Cold Node（慢速存储）←→ Frozen Node（只读快照）

• Hot Node：处理当前写入和高频查询，使用高性能 SSD
• Warm Node：索引不再写入但仍需查询，数据量中等
• Cold Node：历史数据，极少查询，使用大容量低成本存储
• Frozen Node：只读快照，按需恢复，成本最低

6.2 ILM 索引生命周期管理

{
  "policy": {
    "phases": {
      "hot": {
        "min_age": "0ms",
        "actions": { "rollover": { "max_age": "7d", "max_size": "50GB" } }
      },
      "warm": {
        "min_age": "30d",
        "actions": { "shrink": { "number_of_shards": 1 }, "forcemerge": { } }
      },
      "cold": {
        "min_age": "90d",
        "actions": { "allocate": { "require": { "data": "cold" } } }
      },
      "delete": {
        "min_age": "365d",
        "actions": { "delete": { } }
      }
    }
  }
}

6.3 快照备份与恢复

# 创建快照
PUT /_snapshot/my_backup/snapshot_20260101
{ "indices": "my-index-*", "include_global_state": false }

# 恢复快照
POST /_snapshot/my_backup/snapshot_20260101/_restore

支持的仓库类型：fs（共享文件系统）、s3、gcs、azure

6.4 Mapping 设计常见陷阱

6.5 容量规划参考

七、补充知识点

7.1 深度分页方案对比

7.2 Ingest Pipeline

Ingest Node 内置数据预处理管道，可替代 Logstash 轻量级 ETL。

PUT /_ingest/pipeline/my-pipeline
{
  "processors": [
    { "json": { "field": "message", "target_field": "parsed" } },
    { "date": { "field": "parsed.timestamp", "formats": ["ISO8601"] } },
    { "remove": { "field": "parsed.raw" } }
  ]
}

7.3 Reindex 数据迁移

POST /_reindex
{
  "source": { "index": "old-index" },
  "dest": { "index": "new-index" }
}

⚠️ 数据量大时对集群负载较高，建议在低峰期执行，设置 wait_for_completion: false 异步执行。

7.4 Kibana 高级功能

本手册由多 Agent 并行检索 + 主 Agent 汇总生成