Elasticsearch 数据处理常见问题

分词器修改与索引重建深度解析

这是 ES 使用中最容易踩坑的问题之一。

为什么不能直接修改分词器？

ES 基于 Lucene 构建，分词器决定了倒排索引如何构建。索引一旦写入，倒排结构就固化了，Lucene 不允许"重新解释"已有索引。

复制代码

// ❌ 这样做会报错！
PUT /my_index/_mapping
{
  "properties": {
    "content": { "type": "text", "analyzer": "ik_max_word" }
  }
}

正确姿势：滚动重建（Rolling Reindex）

四步标准流程：

步骤 1：创建新索引，配置新分词器

复制代码

PUT /my_index_v2
{
  "settings": {
    "number_of_shards": 6,
    "analysis": {
      "analyzer": {
        "my_ik": {
          "type": "custom",
          "tokenizer": "ik_max_word"
        }
      }
    }
  },
  "mappings": {
    "properties": {
      "content": { "type": "text", "analyzer": "my_ik", "search_analyzer": "ik_smart" }
    }
  }
}

步骤 2：全量 Reindex（核心）

复制代码

POST /_reindex?requests_per_second=500&slices=auto
{
  "source": { "index": "my_index", "size": 1000 },
  "dest": { "index": "my_index_v2" }
}

关键参数：

requests_per_second=500：限流，防止压垮源集群
slices=auto：并行分片，大幅提升速度
size=1000：每批文档数

实测效果（10亿文档，3节点）：默认 Reindex 需 36 小时且 CPU 90%+；限流 + slices 仅需 18 小时，CPU 50%，线上服务无感。

步骤 3：切换别名（原子操作，零停机）

复制代码

POST /_aliases
{
  "actions": [
    { "remove": { "index": "my_index", "alias": "my_alias" }},
    { "add": { "index": "my_index_v2", "alias": "my_alias" }}
  ]
}

步骤 4：验证后删除旧索引

超大规模数据的高级策略

策略 A：按时间分批 Reindex

复制代码

POST /_reindex
{
  "source": {
    "index": "my_index",
    "query": { "range": { "@timestamp": { "gte": "2026-01-01", "lt": "2026-02-01" } } }
  },
  "dest": { "index": "my_index_v2" }
}

每天/每周跑一批，负载可控，失败可重试单批次。

策略 B：Spark/Flink 分布式 Reindex

从 ES 读取原始 _source，在外部集群用新分词器处理后写入新 ES 索引，适合 TB 级数据。

策略 C：双写过渡期

应用层同时写旧索引和新索引，或用 Kafka 做消息回放，适用于不能停写的场景。

其他常见数据处理问题

数据一致性问题

现象：MySQL 修改了数据，但 ES 搜索出来的还是旧数据。

原因：无论通过 Canal 监听 Binlog 还是通过 MQ 异步同步，都会有毫秒到秒级的延迟。

对策：

搜索场景追求最终一致性，允许秒级延迟
强一致性业务（如库存）以 MySQL 为准
定期运行对账任务：按时间窗口滚动对比 MySQL 和 ES 数据，对不一致的数据重新同步

深分页问题

现象：from=9990, size=10 时极其缓慢甚至报错。

原因：假设有 5 个分片，查第 10000 条数据，每个分片都要查出前 10010 条返回给协调节点，协调节点合并 50050 条后丢弃前 10000 条。内存和网络消耗随页码呈指数级上升。

解决方案：

使用 search_after 替代 from/size（推荐）
使用 scroll API（适合导出数据场景）
业务层面限制最大页码

删除数据后磁盘空间不减少

原因：Lucene 的 Segment 文件是不可变的，删除操作只是在 Segment 里标记"删除位"，并未真正从物理磁盘抹掉数据。

复制代码

# 强制合并段文件，物理删除带删除标记的数据
POST /my_index/_forcemerge?max_num_segments=1

注意：Force Merge 是重量级操作，应在低峰期执行。

批量更新导致集群阻塞

原因：ES 更新文档时，会标记旧文档为已删除，然后为新文档创建新版本并索引。大量更新会导致删除标记累积、段文件臃肿、磁盘 I/O 压力剧增。

安全执行检查清单：

更新前禁用自动刷新：index.refresh_interval: -1
使用 requests_per_second 限流
调整合并线程数：merge.scheduler.max_thread_count: 1
更新完成后恢复刷新间隔
必要时执行 Force Merge

问题领域	核心原则	推荐方案
数据同步	异步解耦，保证幂等	Canal + MQ 或 Flink CDC
分词器修改	不可原地修改，必须 Reindex	滚动重建 + 别名切换
数据一致性	接受最终一致性	对账任务 + 补偿机制
深分页	避免 from/size 大偏移	search_after
删除不释放空间	Segment 不可变	Force Merge
批量更新	控制节奏，防止压垮集群	限流 + 禁用刷新 + 分批

核心经验：ES 是"写时固化"的系统------分词器、mapping 在索引创建时就已确定，后续变更必须通过重建索引实现。生产环境中任何大规模数据操作（Reindex、Force Merge、批量更新）都必须遵循"限流、分批、监控、回滚"八字方针。