💎一站式轻松地调用各大LLM模型接口,支持GPT4、智谱、星火、月之暗面及文生图 广告
### 文档 ID 文档唯一标识由四个元数据字段组成: `_id`:文档的字符串 ID `_type`:文档的类型名 `_index`:文档所在的索引 `_uid`:`_type` 和 `_id` 连接成的 `type#id` 默认情况下,`_uid` 是被保存(可取回)和索引(可搜索)的。`_type` 字段被索引但是没有保存,`_id` 和 `_index` 字段则既没有索引也没有储存,它们并不是真实存在的。 尽管如此,你仍然可以像真实字段一样查询 `_id` 字段。Elasticsearch 使用 `_uid` 字段来追溯 `_id`。虽然你可以修改这些字段的 `index` 和 `store` 设置,但是基本上不需要这么做。 `_id` 字段有一个你可能用得到的设置:`path` 设置告诉 Elasticsearch 它需要从文档本身的哪个字段中生成 `_id` ``` PUT /my_index { "mappings": { "my_type": { "_id": { "path": "doc_id" <1> }, "properties": { "doc_id": { "type": "string", "index": "not_analyzed" } } } } } ``` <!-- SENSE: 070_Index_Mgmt/33_ID_path.json --> <1> 从 `doc_id` 字段生成 `_id` 然后,当你索引一个文档时: ``` POST /my_index/my_type { "doc_id": "123" } ``` <!-- SENSE: 070_Index_Mgmt/33_ID_path.json --> `_id` 值由文档主体的 `doc_id` 字段生成。 ``` { "_index": "my_index", "_type": "my_type", "_id": "123", <1> "_version": 1, "created": true } ``` <1> `_id` 正确的生成了。 警告:虽然这样很方便,但是注意它对 `bulk` 请求(见【bulk 格式】)有个轻微的性能影响。处理请求的节点将不能仅靠解析元数据行来决定将请求分配给哪一个分片,而需要解析整个文档主体。