ElasticSearch 基础数据管理详解
文章目录
- [**ElasticSearch 基础数据管理详解**](#ElasticSearch 基础数据管理详解)
-
- [一、ElasticSearch 核心概念](#一、ElasticSearch 核心概念)
-
- [1.1 搜索引擎基础知识](#1.1 搜索引擎基础知识)
- [1.2 倒排索引详解](#1.2 倒排索引详解)
-
- [正排索引(Forward Index)](#正排索引(Forward Index))
- [倒排索引(Inverted Index)](#倒排索引(Inverted Index))
- 倒排索引的核心数据结构
- [1.3 ElasticSearch 常用术语](#1.3 ElasticSearch 常用术语)
- [二、ElasticSearch 索引操作详解](#二、ElasticSearch 索引操作详解)
- [三、ElasticSearch 文档操作详解](#三、ElasticSearch 文档操作详解)
- 四、总结
前言:本文系统梳理 ElasticSearch 核心概念、索引操作与文档操作,帮助读者建立完整的 ES 数据管理知识体系。
一、ElasticSearch 核心概念
1.1 搜索引擎基础知识
ElasticSearch(简称 ES)功能的核心是搜索引擎。理解搜索引擎的基础知识,对于掌握 ES 核心概念至关重要。
什么是全文检索
全文检索(Full-Text Search) 是一种从大量文本数据中快速检索出包含指定词汇或短语的信息的技术。它允许用户输入一个或多个关键词,然后系统会在预先建立好的索引中查找包含这些关键词的文档或文档片段,并返回给用户。
全文检索广泛应用于搜索引擎、文档管理系统、电子邮件客户端、新闻聚合网站等场景,帮助用户快速定位所需信息,提高检索效率和准确性。
查询 vs 检索的区别
- 查询:有明确的搜索条件边界。例如:年龄 15~25 岁、颜色 = 红色、价格 < 3000。这些条件都有明确的范围界定。
- 检索 :即全文检索,无搜索条件边界,召回结果取决于相关性。其相关性计算无明确边界性条件,同义词、谐音、别名、错别字、混淆词、网络热梗等均可成为相关性判断依据。
全文检索的实现原理
全文检索的实现主要包含两个核心步骤:
-
索引构建阶段:
- 对文本数据进行预处理,包括分词、去除停用词等
- 对处理后的文本数据建立倒排索引(Inverted Index)
- 索引记录每个单词在文档中的位置信息、词频、权重等元数据
- 倒排索引将单词映射到包含该单词的文档列表,以便快速定位相关文档
-
搜索查询阶段:
- 搜索引擎根据用户提供的关键词或短语,在建立好的索引中查找匹配的文档
- 根据索引中的信息计算文档的相关性,并按相关性排序返回结果
- 用户可通过不同的搜索策略和过滤条件精确控制搜索结果的质量和范围
为什么传统关系型数据库不适合全文检索
以 MySQL 为例,如果使用 LIKE "%关键词%" 进行模糊查询:
sql
SELECT * FROM t_blog WHERE content LIKE "%Java设计模式%"
这种方式需要遍历所有记录进行匹配,存在两大问题:
- 效率极低:数据量增大时性能急剧下降
- 结果不符合期望:无法基于语义相关性进行排序
1.2 倒排索引详解
正排索引(Forward Index)
正排索引是将文档按顺序排列并进行编号的索引结构。每个文档包含完整的文本内容及相关属性(标题、作者、发布日期等)。
- 特点:可根据文档编号或其他属性快速定位和访问文档内容
- 适用场景:需要对文档进行整体检索和展示
- 局限性:对于包含大量文本内容的数据集,存储和查询效率受限
- 典型应用:MySQL 中通过 ID 查找记录
倒排索引(Inverted Index)
倒排索引是根据单词或短语建立的索引结构,将每个单词映射到包含该单词的文档列表。
建立过程:
- 对文档进行分词处理
- 记录每个单词在哪些文档中出现,以及出现的位置信息
- 通过倒排索引,可根据关键词快速找到包含这些词语的文档,并确定相关性
适用场景:大规模文本数据中的关键词搜索和相关性排序,能够快速定位文档,提高搜索效率。
倒排索引实现步骤:
- 文档预处理:分词、移除停用词、词干提取
- 构建词典:将处理后的词汇添加到词典,分配唯一 ID
- 创建倒排列表:为每个词汇创建列表,记录出现的文档及位置信息
- 存储索引文件:将词典和倒排列表存储在磁盘,通常进行压缩处理
- 查询处理:从词典查找关键词对应的倒排列表,根据文档 ID 快速定位文档
倒排索引的核心数据结构
倒排索引在物理存储上主要由两部分组成,这种设计兼顾了查询速度与存储效率:
1. 词典(Term Dictionary)
- 存储经过分词、归一化后的所有唯一词汇
- 采用**前缀压缩(FST,Finite State Transducer)**存储,空间极小且支持快速前缀查找
- 类比:就像字典的"检字表",告诉你"词在哪个倒排列表里"
2. 倒排列表(Posting List)
- 每个词对应一个列表,记录包含该词的所有文档 ID 、词频(TF) 、位置信息 、偏移量等
- 文档 ID 通常采用增量编码 + 变长压缩(Variable Length Encoding),大幅节省空间
- 类比:就像字典中每个字后面的"页码列表",告诉你"词出现在哪些文档的什么位置"
查询时的协作流程:
用户输入"Java" → 在 Term Dictionary 中定位"Java"
→ 获取对应的 Posting List
→ 根据文档 ID 列表快速召回文档
→ 结合 TF/IDF 等算法计算相关性排序
为什么 ES 比 MySQL 的 LIKE 快?
MySQL 的
LIKE "%Java%"需要逐行扫描文本内容(正排思维),时间复杂度 O(N);而 ES 通过 Term Dictionary 直接定位到 Posting List(倒排思维),时间复杂度接近 O(1),这才是"倒排"的真正威力所在。
1.3 ElasticSearch 常用术语
可通过对比 MySQL 来理解 ES 概念。注意:在 ES 6.x 之前,索引类似于 SQL 数据库,type 类似于表;从 ES 7.x 开始,类型已被弃用,一个索引只能包含一个文档类型。
索引(Index)
索引是 ES 中用于存储和管理相关数据的逻辑容器,可看作数据库中的一个表。它包含了一组具有相似结构的文档,数据以 JSON 格式的文档存储在索引内。
- 每个索引具有唯一的名称(必须全部小写)
- 用于执行搜索、更新和删除操作时引用
- 通过将数据划分为不同索引,可更有效地管理和查询相关数据
映射(Mapping)
映射类似于关系型数据库中的 Schema,可近似理解为"表结构"。它定义了索引中文档的字段及其类型。
映射示例:
json
PUT /employee
{
"mappings": {
"properties": {
"name": {
"type": "keyword"
},
"sex": {
"type": "integer"
},
"age": {
"type": "integer"
},
"address": {
"type": "text",
"analyzer": "ik_max_word"
},
"remark": {
"type": "text",
"analyzer": "ik_smart"
}
}
}
}
设计映射时需考虑:字段名称、字段类型、是否需要分词、是否需要索引、是否需要存储、是否需要多字段类型等。
文档(Document)
文档是 ES 的基本存储单元,指存储在索引中的 JSON 对象。文档中的数据由键值对构成:键是字段名称,值是不同数据类型的字段值。
常用数据类型:字符串、数字、布尔、对象等。
文档元数据:
| 字段 | 说明 |
|---|---|
_index |
文档所属的索引名 |
_type |
文档所属的类型名(已弃用) |
_id |
文档唯一 ID |
_source |
文档的原始 JSON 数据 |
_version |
文档版本号,修改删除时自增 1 |
_seq_no |
数据更改时累计,Shard 级别严格递增 |
_primary_term |
用于恢复数据时处理冲突,Primary Shard 重新分配时递增 |
二、ElasticSearch 索引操作详解
2.1 索引的实战场景
索引是具有相同结构的文档集合,由唯一索引名称标定。
场景一:按业务类型划分
- 微博业务:
weibo_index - 新闻业务:
news_index - 博客业务:
blog_index
不同索引的字段个数、字段名称、字段类型可能不完全一致。
场景二:按日期切分存储日志
- 2024 年 7 月日志:
logs_202407 - 2024 年 8 月日志:
logs_202408
同属一类索引,考虑日志新旧重要程度、数据量规模、索引分片大小和检索性能,按时间维度切分。
2.2 索引的基本操作
创建索引
基本语法:
json
PUT /index_name
{
"settings": {
// 索引设置
},
"mappings": {
"properties": {
// 字段映射
}
}
}
必要参数:
| 参数 | 说明 |
|---|---|
index_name |
索引名称,必须小写,可包含数字和下划线 |
settings |
索引设置 |
mappings |
字段映射定义 |
Settings 关键配置:
-
分片数量(number_of_shards):决定索引的并行度和数据分布
json"number_of_shards": 1 -
副本数量(number_of_replicas):提高数据可用性和容错能力
json"number_of_replicas": 1
Mappings 字段属性:
常用字段类型:text、keyword、integer、float、date 等。
json
"properties": {
"field1": {
"type": "text"
},
"field2": {
"type": "keyword"
}
}
简写创建(仅定义索引名):
json
# 创建索引
PUT /myindex
# 查看索引
GET /myindex
实践练习:创建 student_index
json
PUT /student_index
{
"settings": {
"number_of_shards": 1,
"number_of_replicas": 1
},
"mappings": {
"properties": {
"name": {
"type": "text"
},
"age": {
"type": "integer"
},
"enrolled_date": {
"type": "date"
}
}
}
}
查询索引
查询操作分为两类:检索索引信息 和搜索索引中的文档。
获取索引信息:
json
GET /index_name
搜索索引中的文档:
json
GET /index_name/_search
{
"query": {
// 查询条件
}
}
示例 :搜索 name 字段包含 "John" 的文档
json
GET /student_index/_search
{
"query": {
"match": {
"name": "John"
}
}
}
修改索引
动态更新 Settings:
json
PUT /index_name/_settings
{
"index": {
"setting_name": "setting_value"
}
}
示例:更新副本数量
json
PUT /student_index/_settings
{
"index": {
"number_of_replicas": 2
}
}
动态更新 Mapping(添加新字段):
json
PUT /index_name/_mapping
{
"properties": {
"new_field": {
"type": "field_type"
}
}
}
示例:添加 grade 字段
json
PUT /student_index/_mapping
{
"properties": {
"grade": {
"type": "integer"
}
}
}
警告:已有字段类型不可修改
ES 的 Mapping 一旦创建,已有字段的数据类型通常不允许修改(例如将
text改为keyword)。如需修改,必须创建新索引并通过_reindexAPI 迁移数据。因此,在规划阶段务必慎重设计字段类型,避免后期重建索引带来的业务中断。错误示例:尝试修改已有字段类型会报错
jsonPUT /student_index/_mapping { "properties": { "name": { "type": "keyword" } } }返回错误:
mapper [name] cannot be changed from type [text] to [keyword]
2.3 索引别名详解
为什么需要别名
ES 创建索引后不允许修改索引名。在以下业务场景中,单一索引无法满足需求:
- 场景 1:面对 PB 级别的增量数据,对外提供服务的是基于日期切分的 n 个不同索引,每次检索都要指定数十个甚至数百个索引,非常麻烦。
- 场景 2:线上提供服务的某个索引设计不合理(如字段分词定义不准确),需要保证对外服务不停止,在不更改业务代码的前提下更换索引。
索引别名可以指向一个或多个索引,并可在任何需要索引名称的 API 中使用,提供极大灵活性:
- 在运行中的集群上透明切换索引
- 对多个索引进行分组组合
- 在索引中的文档子集上创建"视图",缩小检索范围,提升效率
如何为索引添加别名
方式一:创建索引时指定别名
json
PUT myindex
{
"aliases": {
"myindex_alias": {}
},
"settings": {
"refresh_interval": "30s",
"number_of_shards": 1,
"number_of_replicas": 0
}
}
方式二:为已有索引添加别名(_aliases API)
json
POST /_aliases
{
"actions": [
{
"add": {
"index": "index_name",
"alias": "alias_name"
}
}
]
}
示例:
json
POST /_aliases
{
"actions": [
{
"add": {
"index": "my_index",
"alias": "my_index_alias"
}
}
]
}
多索引检索的实现方案
不使用别名的方案:
-
方式一:逗号分隔多个索引名
jsonPOST tlmall_logs_202401,tlmall_logs_202402,tlmall_logs_202403/_search -
方式二:使用通配符
jsonPOST tlmall_logs_*/_search
使用别名的方案:
-
使别名关联已有索引:
jsonPOST _aliases { "actions": [ { "add": { "index": "tlmall_logs_202401", "alias": "tlmall_logs_2024" }}, { "add": { "index": "tlmall_logs_202402", "alias": "tlmall_logs_2024" }}, { "add": { "index": "tlmall_logs_202403", "alias": "tlmall_logs_2024" }} ] } -
使用别名进行检索:
jsonPOST tlmall_logs_2024/_search
注意:别名和基于索引的检索效率是一致的,因为索引别名只是物理索引的软链接。但建议相同别名的物理索引有一致的映射,且写入和更新时仍需使用物理索引。
注意:别名不适合直接写入
虽然可以通过别名执行查询操作,但写入、更新、删除文档时建议使用物理索引名。若别名指向多个索引,写入操作会因路由歧义而报错。若别名指向单个索引,写入可以成功,但生产环境中仍建议显式使用物理索引名,避免后续别名指向变更导致写入异常。
三、ElasticSearch 文档操作详解
3.1 文档的介绍
文档是 ES 的基本存储单元,指存储在索引中的 JSON 对象。
3.2 文档的基本操作
新增文档
使用 POST 请求(不指定 ID)
当不指定文档 ID 时,ES 会自动生成唯一 ID:
json
POST /<index_name>/_doc
{
"field1": "value1",
"field2": "value2"
}
使用 PUT 请求(指定 ID)
当指定了文档的唯一标识(ID)时,可新增或更新文档:
json
PUT /<index_name>/_doc/<document_id>
{
"field1": "value1",
"field2": "value2"
}
- 若 ID 不存在,创建新文档
- 若 ID 已存在,替换现有文档
PUT 与 POST 的区别:
| 特性 | PUT | POST |
|---|---|---|
| 指定文档 ID | 必须指定 | 可选,不指定则自动生成 |
| 幂等性 | 幂等 | 非幂等,多次执行可能创建多个文档 |
| 更新行为 | 替换整个文档 | 可使用 _update API 只更新特定字段 |
示例:
json
# 指定 ID 新增
PUT /employee/_doc/1
{
"name": "张三",
"sex": 1,
"age": 25,
"address": "广州天河公园",
"remark": "java developer"
}
# 不指定 ID 新增
POST /employee/_doc
{
"name": "张三",
"sex": 1,
"age": 25,
"address": "广州天河公园",
"remark": "java developer"
}
响应结果解析:
json
{
"_index": "employee",
"_id": "1",
"_version": 1,
"result": "created",
"_shards": {
"total": 2,
"successful": 1,
"failed": 0
},
"_seq_no": 0,
"_primary_term": 1
}
| 字段 | 含义 | 调试价值 |
|---|---|---|
result |
created(新建)/updated(覆盖)/noop(无变化) |
快速判断操作是否如预期 |
_version |
文档版本号,每次修改自增 1 | 用于乐观锁并发控制,排查冲突 |
_seq_no |
分片级别的严格递增序号 | 与 _primary_term 配合实现精确一次处理 |
_shards |
successful 小于 total 时说明副本写入异常 |
排查数据不一致问题的关键线索 |
批量新增文档(_bulk API)
_bulk API 允许将多个索引、更新或删除操作组合成一个请求,提高批量操作效率。
基本语法:
json
POST /<index_name>/_bulk
{ "index" : { "_index" : "<index_name>", "_id" : "<optional_document_id>" } }
{ "field1" : "value1", "field2" : "value2", ... }
{ "update" : { "_index" : "<index_name>", "_id" : "<document_id>" } }
{ "doc" : {"field1" : "new_value1", "field2" : "new_value2", ... }, "_op_type" : "update" }
{ "delete" : { "_index" : "<index_name>", "_id" : "<document_id>" } }
_bulk API 支持的操作类型:
| 操作类型 | 说明 |
|---|---|
index |
创建新文档或替换已有文档 |
create |
文档不存在则创建,已存在则返回错误 |
update |
更新现有文档 |
delete |
删除指定文档 |
示例:
json
# Create 操作
POST _bulk
{"create":{"_index":"article","_id":3}}
{"id":3,"title":"fox老师","content":"fox老师666","tags":["java","面向对象"],"create_time":1554015482530}
{"create":{"_index":"article","_id":4}}
{"id":4,"title":"mark老师","content":"mark老师NB","tags":["java","面向对象"],"create_time":1554015482530}
# Index 操作
POST _bulk
{"index":{"_index":"article", "_id":3}}
{"id":3,"title":"图灵徐庶老师","content":"图灵学院徐庶老师666","tags":["java", "面向对象"],"create_time":1554015482530}
{"index":{"_index":"article", "_id":4}}
{"id":4,"title":"图灵诸葛老师","content":"图灵学院诸葛老师NB","tags":["java", "面向对象"],"create_time":1554015482530}
注意:批量操作不保证原子性
_bulk中某个操作失败不会影响其他操作。务必检查响应中的errors字段和每个 item 的status,避免"部分成功"的静默数据问题。生产环境建议每批控制在 5-15MB 或 1000-5000 条文档之间,以平衡吞吐量与内存压力。
响应结果解析:
json
{
"took": 30,
"errors": false,
"items": [
{
"index": {
"_index": "article",
"_id": "3",
"_version": 1,
"result": "created",
"_shards": { "total": 2, "successful": 1, "failed": 0 },
"status": 201
}
}
]
}
| 字段 | 含义 |
|---|---|
took |
整个批量请求消耗的时间(毫秒) |
errors |
是否有任何操作失败,false 不代表全部成功,需逐条检查 status |
items |
每个操作对应的响应结果,按请求顺序排列 |
status |
HTTP 状态码,201 为创建成功,200 为更新/删除成功,409 为版本冲突等 |
实践练习:批量插入员工信息
- 创建员工索引:
json
PUT /employee
{
"settings": {
"number_of_shards": 1,
"number_of_replicas": 1
},
"mappings": {
"properties": {
"name": {
"type": "keyword"
},
"sex": {
"type": "integer"
},
"age": {
"type": "integer"
},
"address": {
"type": "text",
"analyzer": "ik_max_word",
"fields": {
"keyword": {
"type": "keyword"
}
}
},
"remark": {
"type": "text",
"analyzer": "ik_smart",
"fields": {
"keyword": {
"type": "keyword"
}
}
}
}
}
}
- 批量插入员工文档:
json
POST /employee/_bulk
{"index":{"_index":"employee","_id":"1"}}
{"name":"张三","sex":1,"age":25,"address":"广州天河公园","remark":"java developer"}
{"index":{"_index":"employee","_id":"2"}}
{"name":"李四","sex":1,"age":28,"address":"广州荔湾大厦","remark":"java assistant"}
{"index":{"_index":"employee","_id":"3"}}
{"name":"王五","sex":0,"age":26,"address":"广州白云山公园","remark":"php developer"}
{"index":{"_index":"employee","_id":"4"}}
{"name":"赵六","sex":0,"age":22,"address":"长沙橘子洲","remark":"python assistant"}
{"index":{"_index":"employee","_id":"5"}}
{"name":"张龙","sex":0,"age":19,"address":"长沙麓谷企业广场","remark":"java architect assistant"}
{"index":{"_index":"employee","_id":"6"}}
{"name":"赵虎","sex":1,"age":32,"address":"长沙麓谷兴工国际产业园","remark":"java architect"}
查询文档
根据 ID 查询单个文档:
json
GET /<index_name>/_doc/<document_id>
根据 ID 批量查询(Multi GET API):
json
GET /<index_name>/_mget
{
"ids" : ["id1", "id2", "id3", ...]
}
示例:
json
# 查询单个文档
GET /employee/_doc/1
# 批量查询多个文档
GET /employee/_mget
{
"ids" : ["1", "2", "3"]
}
响应结果解析(单文档查询):
json
{
"_index": "employee",
"_id": "1",
"_version": 1,
"_seq_no": 0,
"_primary_term": 1,
"found": true,
"_source": {
"name": "张三",
"sex": 1,
"age": 25,
"address": "广州天河公园",
"remark": "java developer"
}
}
| 字段 | 含义 |
|---|---|
found |
true 表示文档存在,false 表示不存在(此时无 _source 字段) |
_source |
文档的原始 JSON 数据,是业务最关心的内容 |
根据搜索关键词查询(Query DSL)
Query DSL 是基于 JSON 的查询语言,用于构建复杂搜索查询。
常用查询语法:
-
匹配所有文档:
jsonGET /<index_name>/_search { "query": { "match_all": {} } } -
文本字段匹配(match):
jsonGET /<index_name>/_search { "query": { "match": { "<field_name>": "<query_string>" } } } -
精确匹配(term,不分词):
jsonGET /<index_name>/_search { "query": { "term": { "<field_name>": { "value": "<exact_value>" } } } } -
范围查询(range):
jsonGET /<index_name>/_search { "query": { "range": { "<field_name>": { "gte": <lower_bound>, "lte": <upper_bound> } } } }
综合示例:
json
# 精确匹配:姓名是张三的员工
GET /employee/_search
{
"query": {
"term": {
"name": "张三"
}
}
}
# 全文检索:查询在广州白云山的员工
GET /employee/_search
{
"query": {
"match": {
"address": "广州白云山"
}
}
}
# 范围查询:查询 age 在 20 至 26 岁之间的员工
GET /employee/_search
{
"query": {
"range": {
"age": {
"gte": 20,
"lte": 26
}
}
}
}
删除文档
删除单个文档:
json
DELETE /<index_name>/_doc/<document_id>
批量删除文档:
-
使用 _bulk API:
jsonPOST /_bulk { "delete": {"_index": "{index_name}", "_id": "{id}"} } { "delete": {"_index": "{index_name}", "_id": "{id}"} } -
使用 _delete_by_query API(根据查询条件删除):
jsonPOST /{index_name}/_delete_by_query { "query": { "<your_query>" } }
示例:
json
# 删除单个文档
DELETE /employee/_doc/1
# 批量删除(_bulk)
POST _bulk
{"delete":{"_index":"employee","_id":3}}
{"delete":{"_index":"employee","_id":4}}
# 按条件删除(删除在广州的员工)
POST /employee/_delete_by_query
{
"query": {
"match": {
"address": "广州"
}
}
}
响应结果解析(删除单文档):
json
{
"_index": "employee",
"_id": "1",
"_version": 2,
"result": "deleted",
"_shards": {
"total": 2,
"successful": 1,
"failed": 0
},
"_seq_no": 1,
"_primary_term": 1
}
| 字段 | 含义 |
|---|---|
result |
deleted 表示删除成功;若文档不存在则返回 not_found |
_version |
删除后版本号仍会递增,用于标记该文档已删除 |
更新文档
更新单个文档(_update API)
允许部分更新现有文档的字段:
json
POST /{index_name}/_update/{id}
{
"doc": {
"<field>": "<value>"
}
}
示例:
json
# 更新员工 id 为 1 的文档,修改年龄为 28
POST /employee/_update/1
{
"doc": {
"age": 28
}
}
注意:区分全量替换与部分更新
PUT /index/_doc/id执行的是全量替换 ,如果新 JSON 只包含部分字段,原有其他字段会被永久删除。_updateAPI 才是部分更新 ,只修改指定字段,其余字段保持不变。在业务开发中,若仅需修改个别字段,务必使用_updateAPI,避免数据丢失。
响应结果解析(_update):
json
{
"_index": "employee",
"_id": "1",
"_version": 2,
"result": "updated",
"_shards": {
"total": 2,
"successful": 1,
"failed": 0
}
}
| 字段 | 含义 |
|---|---|
result |
updated 表示字段值发生变化;若新值与旧值相同则返回 noop,版本号不递增 |
批量更新文档:
-
使用 _bulk API:
jsonPOST /_bulk { "update" : {"_index" : "<index_name>", "_id" : "<document_id>"} } { "doc" : {"field1" : "new_value1", "field2" : "new_value2"}, "upsert" : {"field1" : "new_value1", "field2" : "new_value2"} }upsert定义了文档不存在时应插入的内容。 -
使用 _update_by_query API(根据查询条件更新):
jsonPOST /<index_name>/_update_by_query { "query": { <!-- 定义更新文档的查询条件 --> }, "script": { "source": "ctx._source.field = 'new_value'", "lang": "painless" } }该操作是原子性的,要么所有匹配文档都被更新,要么一个都不会被更新。
四、总结
| 操作类型 | 单个操作 | 批量操作 |
|---|---|---|
| 新增 | POST /index/_doc 或 PUT /index/_doc/id |
_bulk API |
| 查询 | GET /index/_doc/id |
GET /index/_mget 或 _search |
| 更新 | POST /index/_update/id |
_bulk API 或 _update_by_query |
| 删除 | DELETE /index/_doc/id |
_bulk API 或 _delete_by_query |
掌握以上 ElasticSearch 基础数据管理操作,是进行 ES 开发和运维的必备技能。建议结合实际业务场景,多加练习,深入理解每个 API 的适用场景和注意事项。
参考资料:本文档基于 ElasticSearch 8.x 版本编写,部分概念和 API 可能因版本差异略有不同,请以官方文档为准。建议结合 Kibana Dev Tools 或 cerebro 等工具进行实践练习。