您当前的位置： 首页 > 慢生活 > 程序人生 网站首页程序人生
elasticSearch版本控制与post、put和delete的关系
发布时间：2021-08-28 16:32:17编辑：雪饮阅读（）
这里允许了默认自动创建索引和映射且没有限制某些个匹配。
首先看post
请求体：
{
"name":"Central School", "description":"CBSE Affiliation", "street":"Nagan",
"city":"paprola", "state":"HP", "zip":"176115", "location":[31.8955385, 76.8380405],
"fees":2200, "tags":["Senior Secondary", "beautiful campus"], "rating":"3.3"
}
响应体：
{
"_index": "schools3",
"_type": "school3",
"_id": "3",
"_version": 1,
"result": "created",
"_shards": {
"total": 2,
"successful": 1,
"failed": 0
},
"_seq_no": 0,
"_primary_term": 1
}
首先，这里shcools3和school3都是不存在的，可见默认第一次请求下来版本是1，这个是内部版本控制是以1开头的默认版本。
那么同样的这样的请求你会发现你再次发起后，版本就变成2了。
接下来看看put请求
请求体
{
"name":"Central School", "description":"CBSE Affiliation", "street":"Nagan",
"city":"paprola", "state":"HP", "zip":"176115", "location":[31.8955385, 76.8380405],
"fees":2200, "tags":["Senior Secondary", "beautiful campus"], "rating":"3.3"
}
响应体：
{
"_index": "schools4",
"_type": "school4",
"_id": "4",
"_version": 2,
"result": "updated",
"_shards": {
"total": 2,
"successful": 1,
"failed": 0
},
"_seq_no": 1,
"_primary_term": 1
}
这里的schools4和school4与上面post请求也是一样的，都是不存在的。
这里会发现随着这个相同的put请求不断请求，版本号也是不断递增的。
接下来看看delete
这里delete的是上面的put请求的文档
请求体：none
响应体：
{
"_index": "schools4",
"_type": "school4",
"_id": "4",
"_version": 5,
"result": "not_found",
"_shards": {
"total": 2,
"successful": 1,
"failed": 0
},
"_seq_no": 4,
"_primary_term": 1
}
这里你同样会发现同一个delete请求不到发送，每次都能执行成功，第二次开始就提示文档不存在not_found，但是响应体中版本号则也是不断的在递增的。
接下来就是post、put、delete对于同一个请求的交叉操作
这里你会发现对于同一个文档，他们三种请求交叉操作，也都是每个操作都能使得版本号增长。
比如post时候是1，put时候就是2了，接下来delete时候就是3了
那么同样的put时候是1，post时候就是2了，接下来delete时候也就是3了
那么你还会发现一个有意思的事情，那就是post时候，假比如对一个put请求之后再进行post请求，可能都是带有文档id的原因，所以post请求不会提示文档已存在，而是result中以updated指示，那么我认为这里post的原理就是带有文档id时候对应文档存在，则和put是一致的。
但是如果是相同的post请求，且不带文档id，则是不断的创建相同的索引/类型，不同id的文档，文档内容也是相同的，id是自动生成的，类似mysql的主键唯一，只是这里的主键不是数字，而是字符串。
关键字词：elasticSearch,post,put,delete,版本控制