概述
| text 类型 | keyword 类型 | |
|---|---|---|
| 核心机制 | 分词处理，建立倒排索引 | 不分词，原样存储 |
| 主要用途 | 全文搜索、模糊匹配 | 精确匹配、过滤、排序、聚合 |
| 分词处理 | 使用分析器（Analyzer）将文本拆分为词条（Terms） | 不进行分词，将整个字符串作为一个词条 |
| 排序与聚合 | 默认不支持，需开启fielddata（消耗内存） |
天然支持，使用doc_values（高效） |
| 查询方式 | match_query（对查询词分词后匹配） |
term_query（精确匹配整个字段值） |
| 典型场景 | 文章正文、商品描述、日志内容等大段文本 | 姓名、标签、状态码、ID、邮编等结构化数据 |
搜索过程
仅 text：
处理流程将完全围绕全文搜索进行：
- 存储（索引）过程：
- 分词分析：当文档被索引时，字段内容会经过指定的分析器进行处理。这个过程包括分词（将句子拆分成单个词条）、过滤停用词、统一转为小写等。
- 构建倒排索引：分词后得到的词条（Terms）会被用来构建倒排索引。倒排索引记录了每个词条出现在哪些文档中，以及出现的位置和频率等。
- 查询过程：
- 当使用 match等全文搜索查询时，ES 会对查询词进行同样的分词处理，然后在倒排索引中查找匹配的词条，最终根据相关性算法（如 BM25）返回最相关的文档。
- 想要实现精准查询，无法用 term查询实现，需用 match_phrase等
仅 keyword：
- 存储（索引）过程：整个字符串被作为一个整体原样存储
- 查询过程：查询词不分词，直接与索引中的完整值比对
- 使用 term查询，要求字符、顺序、大小写等完全一致
- 类似于关系数据库中的 WHERE id = 'xxx'
text和 keyword多字段类型：
-
定义方法：
"XXX": {
"type": "text", // 主字段用于全文搜索
"fields": {
"keyword": { // 子字段用于精确匹配
"type": "keyword",
"ignore_above": 256 // 可选，超过此长度的值不被索引，尽量减少对性能的影响
}
}
} -
存储（索引）过程：
- text路径：文本会一样被分词，并构建倒排索引
- keyword路径：同时，原始的完整文本会作为一个整体被保留（不进行分词），并通常被加入到 doc_values 中（一种列式存储结构），使得该字段支持精确匹配、排序和聚合操作
-
查询过程：
- 进行全文搜索时，使用字段本身，走 text路径
- 当需要进行精确匹配、排序或聚合（统计不同 document 内容出现的次数）就需要使用 log.keyword这个子字段，查询会直接匹配整个字符串