//
#给数字自加值
GET /myindex/_update/article2
{
"script":"ctx._source.age+=1"
}
#给字符串追加
GET /myindex/_update/article2
{
"script":"ctx._source.content+='hehe'"
}
#给数组添加元素
GET /myindex/_update/article2
{
"script":{
"source":"ctx._source.test.add(params.tag)",
"params":{
"tag": "football"
}
}
}
#删除数组元素
GET /myindex/_update/article2
{
"script":{
"source":"ctx._source.test.remove(ctx._source.test.indexOf(params.tag))",
"params":{
"tag": "football"
}
}
}
#按条件删除文档
GET /myindex/_update/article2
{
"script":{
"source":"ctx.op=ctx._source.age==params.count?'delete':'none'",
"params":{
"count": 21
}
}
}
#upsert操作，有记录update，没记录insert
GET /myindex/_update/article2 #
{
"script":"ctx._source.age+=1",
"upsert":{
"post_date" : "2019-06-15",
"tile" : "es",
"content" : "100 years old",
"id" : 122,
"age" : 100,
"test" : [
"fishing",
"very good"
],
"intrest" : "xi huan driving"
}
}
#post请求采用的是乐观锁 即version值+1
POST /myindex/_update/article2
{
"script":"ctx._source.age+=1",
"upsert":{
"post_date" : "2019-06-15",
"tile" : "es",
"content" : "100 years old",
"id" : 122,
"age" : 100,
"test" : [
"fishing",
"very good"
],
"intrest" : "xi huan driving"
}
}
#如果执行失败了，请求会重新获取文档数据和版本信息进行更新
#能够重试的次数是retry_on_conflict指定
POST /myindex/_update/article2?retry_on_conflict=3&version=5
数据路由
es判断决定文档数据存储在哪个分片上的过程叫数据路由。
路由算法：
sard=hash(routing) % primary_shard_num
- 每次增删改查时，都有一个routing值，默认是文档的id
- 对这个routing值进行hash取余运算
- routing值默认是文档的id，也可以手动指定一个值。
- 手动指定routing值对于负载均衡以及提高批量读取的性能都有帮助
- primary_shard个数一旦确定就不能修改了
3.1.5 写一致性原理和quorum机制
1.任何一个增删改槽作都可以跟上一个参数consistency，可以给该参数指定的值：
one : (primary shard)只要有一个primary shard是活跃的就可以执行
all : {all shard)所有的primary shard和replica shard都是活跃的才会执行
quorum: (default)默认值，大部分shard是活跃的才能执行（例如共有6个shard,至少有3个shard是活跃的才会执行写操作）
2.quorum机制：多数shard都是可用的
int ( (primary+number_of_replica) / 2 ) + 1
例如：3个primary shard, 1 个replica
int ( ( 3 + 1 ) / 2 ) + 1 = 3
至少3个shard是活跃的
注意：可能出现shard不能分配齐全的情況
比如：1个primary shard,1个replica int ( (1 + 1) / 2) + 1 = 2，但是如果只有一个节点，因为primary shard和replica shard不能在同一个节点上，所以仍然不能执行写操作
再举例：1 个primary shard,3个replica,2个节点
int((1+3)/2)+1 =3
最后: 当活跃的shard的个数没有达到要求时，es默认会等待一分钟，如果在等待的期间活跃的shard的个数没有增加，则显示timeout
PUT /index/type/id?timeout=60m
3.16文档查询内部原理
笫一步：查词请求发给任息一个节点，该节点就成了coordinating node,该节点使用路由算法算出文档所在的primary shard
第二步：协调节点把请求转发给primary shard也可以转发给replica shard(使用轮询调度算法(Round-Robin Scheduling,把请求平均分配至primary shard
和replica shard)
笫三步：处理请求的节点把结果返回给协调节点，协调节点再返回给应用程序
特殊情况：请求的文档还在建立索引的过程中，primary shard上存在，但replica shard上不存在，但是请求被转发到了replica shard上，这时就提示找不到
3.17 bulk批量操作的json格式解析
bulk的格式：
{action:{metadata}}\n
{requstbody}\n
为什么不使用如下格式？
[{"action": { },"data":{ }}]
这种方式可读性好，但是内部处理就麻烦了:
- 将json数组解析为JSONArray対象，在内存中就需要有Dson文本的拷贝，另外还有一个JSONArray对象.
- 解忻json数组里的每个json,对毎个谲求中的document进行路甶
- 为路由到同一个shard上的多个请求，创建一个谲求数组
- 将这个请求数组序列化
- 将序列化后的谮求数组发送到对应的节点上去
耗费更多内存，增加java虚拟机开销
1.不用持其转換为json对象，直接按照换行符切割json,内存中不需要json文本的拷贝
2.对每两一组的json,读取meta,进行document路由
3.直接将对应的json发送到node上去
3.18查询结果分析
默认有分页，只查出10条数据
took : 查询耗费的时间，单位是毫秒
shards : 共请求了多少个shard
