ELK Stack中Schema on read与读时字段提取及runtime fields关联问题

1. 读时字段提取与Schema on reading的关联 #

两者是顶层设计思想和具象落地能力的对应关系：

• Schema on reading（读时模式）是底层数据处理架构的核心设计理念：和传统写时模式（Schema on write）要求写入前必须预先定义固定数据结构不同，它允许写入阶段不对数据结构做强制约束，所有结构判定、字段解析逻辑全部后移到数据读取/查询阶段执行，核心优势是适配异构半结构化/非结构化数据源，无需提前建模，写入性能更高。
• 读时字段提取是Schema on reading理念在字段解析场景下的具象实现手段：它完全符合「将字段定义、解析逻辑从索引/写入阶段后移到查询阶段」的核心要求，是Schema on reading落地时最常用的功能之一。

总结来说：Schema on reading是读时字段提取的设计依据，读时字段提取是Schema on reading的典型落地载体。

2. Elasticsearch Runtime Field的定位 #

Runtime Field是Elasticsearch生态中对接上述两者的核心功能载体，定位非常明确：

• 它是Schema on reading设计思想在ES中的原生功能实现：无需在建索引时提前定义字段Mapping，也不需要在数据写入阶段提前做字段抽取，所有字段逻辑都可以在查询阶段临时定义，完全符合读时模式的核心要求。
• 它是读时字段提取能力的直接实现接口：所有需要在查询阶段临时完成的字段抽取、格式转换、逻辑计算，都可以通过定义Runtime Field实现。比如从原始日志message字段中临时提取响应码、接口路径，或是对时间戳做格式转换，这类操作都不需要修改索引结构、不需要重新索引数据，全部在查询阶段实时计算完成，是标准的读时字段提取实现。

举个简单的使用示例：假设你的索引中只有原始的message字段，内容形如2024-05-20 12:34:56 GET /api/user 200 123ms，不需要提前建字段，直接在查询时定义Runtime Field即可按响应码筛选数据：

{
  "runtime_mappings": {
    "response_code": {
      "type": "integer",
      "script": {
        "source": "emit(Integer.parseInt(doc['message'].value.split(' ')[3]))"
      }
    }
  },
  "query": {
    "term": {
      "response_code": 200
    }
  }
}

内容的提问来源于stack exchange，提问作者M-E