MultiGet

ES系列四、ES6.3常用api之文档类api

落爺英雄遲暮 — Sat, 26 Dec 2020 17:00:22 +0000

ES系列四、ES6.3常用api之文档类api 落爺英雄遲暮 2020-12-27 01:00:22

1.Index API: 创建并建立索引

PUT twitter/tweet/1
{
     "user" : "kimchy",
     "post_date" : "2009-11-15T14:12:12",
     "message" : "trying out Elasticsearch"
}

官方文档参考：Index API。

2.Get API: 获取文档

curl -XGET 'http://localhost:9200/twitter/tweet/1'

官方文档参考：Get API。

3.DELETE API: 删除文档

$ curl -XDELETE 'http://localhost:9200/twitter/tweet/1'

官方文档参考：Delete API。

4.UPDATE API: 更新文档

PUT test/type1/1{ "counter" : 1, "tags" : ["red"]}

官方文档参考：Update API。

5.Multi Get API: 一次批量获取文档

PUT 'localhost:9200/_mget
{ 
    "docs" :
    [
       {"_index" : "test", 
         "_type" : "type",
           "_id" : "1" 
        },
       { "_index" : "test",
          "_type" : "type",
            "_id" : "2" 
        }
     ]
}

官方文档参考：Multi Get API。

6.Bulk API: 批量操作，增删改查

1.本地文件批量操作

e$ curl -s -XPOST localhost:9200/blog/user/_bulk --data-binary @requests
requests文件内容如下
{"index":{"_id":"25"}}
{"name":"黎明","id":25}
{"index":{"_id":"26"}}
{"name":"小明","id":26}
{"index":{"_id":"26"}}
{"name":"雄安","id":27}
{"index":{"_id":"28"}}
{"name":"笑话","id":28}

2.resp 方法

curl -H "Content-Type: application/json" -XPOST 'http://47.52.199.51:9200/book/english/_bulk' -d'
{"index":{"_id":"17"}}
{"name":"cddd","id":17}
{"index":{"_id":"18"}}
{"name":"cddd","id":18}
{"index":{"_id":"19"}}
{"name":"cddd","id":19}
{"index":{"_id":"20"}}
{"name":"cddd","id":20}
'

官方文档参考：Bulk API。

7.DELETE By Query API: 查询删除

POST /book/_delete_by_query
{
　　"query":{
　　　　"match":{
　　　　"name": "yangxioa"
　　　　}
　　}
}

7.1.删除所有

POST /book/_delete_by_query
{
    "query":{
        "match_all":{}
    }
}

7.2.支持路由查询（routing=XXX,匹配分片数）

POST twitter/_delete_by_query?routing=1
{
  "query": {
    "range" : {
        "age" : {
           "gte" : 10
        }
    }
  }
}

{
  "took" : 147, // 整个操作从开始到结束的毫秒数
  "timed_out": false, // true如果在通过查询执行删除期间执行的任何请求超时 ，则将此标志设置为。
  "total": 119, // 已成功处理的文档数。
  "deleted": 119, // 已成功删除的文档数。
  "batches": 1,  // 通过查询删除拉回的滚动响应数。
  "version_conflicts": 0, // 按查询删除的版本冲突数。
  "noops": 0, // 对于按查询删除，此字段始终等于零。它只存在，以便通过查询删除，按查询更新和reindex API返回具有相同结构的响应。
  "retries": { // 通过查询删除尝试的重试次数。bulk是重试的批量操作search的数量，是重试的搜索操作的数量。
    "bulk": 0,
    "search": 0
  },
  "throttled_millis": 0, // 请求睡眠符合的毫秒数requests_per_second。
  "requests_per_second": -1.0, // 在通过查询删除期间有效执行的每秒请求数。
  "throttled_until_millis": 0, //在按查询响应删除时，此字段应始终等于零。它只在使用Task API时有意义，它指示下一次（自纪元以来的毫秒数），为了符合，将再次执行受限制的请求
  "failures" : [ ] 
   //如果在此过程中存在任何不可恢复的错误，则会出现故障数组。如果这是非空的，那么请求因为那些失败而中止。逐个查询是使用批处理实现的，
   任何故障都会导致整个进程中止，但当前批处理中的所有故障都会被收集到数组中。您可以使用该conflicts选项来防止reindex在版本冲突中中止。
}

官方文档参考：Delete By Query API。

8.update更新api

8.1.脚本更新

POST test/_doc/1/_update
   {
    "script" : {
        "source": "ctx._source.counter += params.count",
        "lang": "painless",// ES语言类型
        "params" : {
            "count" : 4
        }
    }
}

8.2.新增字段

POST test/_doc/1/_update
{
    "script" : "ctx._source.new_field = 'value_of_new_field'"
}

8.3.删除字段

POST test/_doc/1/_update
{
    "script" : "ctx._source.remove('new_field')"
}

8.4.存在就更新

POST test/_doc/1/_update
{
    "script" : {
        "source": "if (ctx._source.tags.contains(params.tag)) { ctx.op = 'delete' } else { ctx.op = 'none' }",
        "lang": "painless",
        "params" : {
            "tag" : "green"
        }
    }
}

8.5.更新部分字段

POST test/_doc/1/_update
{
    "doc" : {
        "name" : "new_name"
    }
}

8.6.upsert：存在就更新，不存在插入

POST test/_doc/1/_update
{
    "script" : {
        "source": "ctx._source.counter += params.count",
        "lang": "painless",
        "params" : {
            "count" : 4
        }
    },
    "upsert" : {
        "counter" : 1
    }
}

官方文档参考：Update 脚本更新API

9.UPDATE BY QUERY API:查询更新

9.1.更新，重新索引

POST twitter/_update_by_query?conflicts=proceed

{
  "took" : 147,
  "timed_out": false,
  "updated": 120,
  "deleted": 0,
  "batches": 1,
  "version_conflicts": 0,
  "noops": 0,
  "retries": {
    "bulk": 0,
    "search": 0
  },
  "throttled_millis": 0,
  "requests_per_second": -1.0,
  "throttled_until_millis": 0,
  "total": 120,
  "failures" : [ ]
}

ES内部自带实现乐观锁控制，先查询出要更新的记录的版本号，更新时匹配版本号时候一致。
所有更新和查询失败都会导致_update_by_query中止并failures在响应中返回。已执行的更新仍然存在。换句话说，该过程不会回滚，只会中止。当第一个失败导致中止时，失败的批量请求返回的所有失败都将在failures元素中返回; 因此，可能存在相当多的失败实体。

如果您只想计算版本冲突，不要导致_update_by_query 中止，您可以conflicts=proceed在URL或"conflicts": "proceed",改配置当第一个冲突时会会继续执行，version_conflicts冲突数量。

9.2.查询更新

POST twitter/_update_by_query?conflicts=proceed
{
  "query": { 
    "term": {
      "user": "kimchy"
    }
  }
}

9.3.查询脚本更新

POST twitter/_update_by_query
{
  "script": {
    "source": "ctx._source.likes++",
    "lang": "painless"
  },
  "query": {
    "term": {
      "user": "kimchy"
    }
  }
}

也可以同时在多个索引和多个类型上完成这一切，就像搜索API一样：

POST twitter，blog / _doc，post / _update_by_query

routing则路由将复制到滚动查询，将进程限制为与该路由值匹配的分片：

POST twitter/_update_by_query?routing=1

默认情况下，_update_by_query使用1000的滚动批次。可以使用scroll_sizeURL参数更改批量大小：

POST twitter/_update_by_query?scroll_size=100

9.4.使用TASK API获取所有正在运行的逐个查询请求的状态

GET _tasks?detailed=true&actions=*byquery

结果：

{
  "nodes" : {
    "r1A2WoRbTwKZ516z6NEs5A" : {
      "name" : "r1A2WoR",
      "transport_address" : "127.0.0.1:9300",
      "host" : "127.0.0.1",
      "ip" : "127.0.0.1:9300",
      "attributes" : {
        "testattr" : "test",
        "portsfile" : "true"
      },
      "tasks" : {
        "r1A2WoRbTwKZ516z6NEs5A:36619" : {
          "node" : "r1A2WoRbTwKZ516z6NEs5A",
          "id" : 36619,
          "type" : "transport",
          "action" : "indices:data/write/update/byquery",
          "status" : {    
            "total" : 6154,
            "updated" : 3500,
            "created" : 0,
            "deleted" : 0,
            "batches" : 4,
            "version_conflicts" : 0,
            "noops" : 0,
            "retries": {
              "bulk": 0,
              "search": 0
            }
            "throttled_millis": 0
          },
          "description" : ""
        }
      }
    }
  }
}

使用任务ID，您可以直接查找任务：

GET /_tasks/taskId:1

可以使用任务取消API取消任何按查询更新：

POST _tasks/task_id:1/_cancel

手动切片：

POST twitter/_update_by_query
{
  "slice": {
    "id": 0,
    "max": 2
  },
  "script": {
    "source": "ctx._source['extra'] = 'test'"
  }
}

官方文档参考：Update By Query API

10.Reindex API：重新索引

10.1.复制整个索引

最基本的形式_reindex只是将文档从一个索引复制到另一个索引。这会将twitter索引中的文档复制到new_twitter索引中(前提是要有相同的索引类型)：

POST _reindex
{
  "source": {
    "index": "twitter"
  },
  "dest": {
    "index": "new_twitter"
  }
}

10.2.复制匹配的文档

POST _reindex
{
  "source": {
    "index": "twitter",
    "type": "_doc",
    "query": {
      "term": {
        "user": "kimchy"
      }
    }
  },
  "dest": {
    "index": "new_twitter"
  }
}

10.3.复制多个索引文档

POST _reindex
{
  "source": {
    "index": ["book", "blog"],
    "type": ["english", "user"]
  },
  "dest": {
    "index": "book1"
  }
 }

ES 6.3只支持一个索引一个类型，所以上面这个并没有实验成功！提示：

"reason": "Rejecting mapping update to [book1] as the final mapping would have more than 1 type: [english, user]"

10.4.是否覆盖版本号

POST reindex 
{
  "source": {
    "index": ["book"],
    "type": ["english"]
  },
  "dest": {
    "index": "book1",
    "version_type":"external"
  }
 }

“external”:表示使用source的版本号覆盖dest的版本号，当source的版本号<=dest的版本号会提示冲突，“internal”:表示保持dest的版本号自增。

10.5.只复制不存在的记录，已经存在的记录提示冲突

POST _reindex
 {
  "source": {
    "index": ["book"],
    "type": ["english"]
  },
  "dest": {
    "index": "book1",
    "op_type": "create"
  }
 }

默认情况下，版本冲突会中止该_reindex过程，但可以通过"conflicts": "proceed"请求正文中的设置对它们进行计数

10.6.排序复制指定数量

POST _reindex
{
    "size":10,
    "source": {
        "index": ["book"],
        "sort": { "name": "desc" }
      },
     "dest": {
        "index": "book1",
        "op_type": "create"
      }
}

如果报错禁止排序：Fielddata is disabled on text fields by...

聚合这些操作用单独的数据结构(fielddata)缓存到内存里了，需要单独开启：

PUT book/_mapping/english

{
  "properties": {
    "name": { 
      "type":     "text",
      "fielddata": true
    }
  }
}

10.7.复制部分字段

POST _reindex
{"source": {
    "index": "book",
     "_source": ["age", "name"]
  },
  "dest": {
    "index": "book1"
  }
}

10.8.过滤修改元数据再复制

POST _reindex

{
  "size":2,
  "source": {
    "index": "book",
     "_source": ["age", "name"]
  },
  "dest": {
    "index": "book1",
    "routing": "=age" // 根据age进行路由

  },
  "script": {
    "source": "if (ctx._source.age == 12) {ctx._source.age++}",
    "lang": "painless"
  }
}

就像在_update_by_query，您可以设置ctx.op更改在目标索引上执行的操作：

noop: 设置 ctx.op = "noop" 脚本是否确定不必在目标索引中编制索引。这种无操作将 noop 在响应机构的计数器中报告。
delete: ctx.op = "delete" 如果脚本确定必须从目标索引中删除文档，请进行设置。

10.9.从远程复制

POST _reindex
{
  "source": {
    "remote": {
      "host": "http://otherhost:9200",
      "username": "user",
      "password": "pass"
    },
    "index": "source",
    "query": {
      "match": {
        "test": "data"
      }
    }
  },
  "dest": {
    "index": "dest"
  }
}

10.10.查看重建索引任务

GET _tasks?detailed=true&actions=*reindex

官方文档参考：Reindex API

11.term Vectors:分词api

11.1. term的基本信息

# term_freq：在在该字段中的频率

# position：词在该字段中的位置

# start_offset：从什么偏移量开始的

# end_offset: 到什么偏移量结束

11.2 term的统计信息

如果启用了term的统计信息，即term_statistics设为true，那么有哪些统计信息呢？

# doc_freq： 该词在文档中出现的频率

# ttf：total term frequency的缩写，一个term在所有document中出现的频率

11.3字段的统计信息

如果启用了字段统计信息，即field_statistics设为true,那么有哪些统计信息呢？

# sum_doc_freq: 一个字段中所有term的文档频率之和

# doc_count: 有多少个文档包含这个字段

# sum_ttf：sum total term frequency的缩写，一个字段中的每一个term的在所有文档出现之和

term statistics和field statistics并不精准，不会被考虑有的doc可能被删除了

11.5采集term信息的方式

采集term信息的方式有两种：index-time(从已经存储的索引中查看) 和 query-time（及时生成）

11.6 index-time方式

需要在mapping配置一下，然后建立索引的时候，就直接生成这些词条和文档的统计信息

PUT /website

{

   "mappings": {

       "article":{

           "properties":{

               "text":{

                   "type": "text",

                   "term_vector": "with_positions_offsets",

                   "store": "true",

                   "analyzer" : "fulltext"

                }

            }

        }

    },

   "settings": {

       "analysis": {

           "analyzer": {

               "fulltext":{

                   "type": "custom",

                   "tokenizer": "whitespace",

                   "filter": [

                        "lowercase",

                       "type_as_payload"

                   ]

               }

            }

        }

    }

}

View Code

11.7 query-time方式

即之前没有在mapping里配置过，而是通过查询的方式产生这些统计信息

POST /ecommerce/music/1/_termvectors

{

   "fields":["desc"],

   "offsets":true,

   "payloads":true,

   "positions":true,

   "term_statistics":true,

   "field_statistics" : true

}

11.8 手动指定analyzer来生成termvector

我么可以通过指定per_field_analyzer设置一个分词器对该字段文本进行分词。

POST /ecommerce/music/1/_termvectors

{

   "fields":["desc"],

   "offsets":true,

   "payloads":true,

   "positions":true,

   "term_statistics":true,

   "field_statistics" : true,

   "per_field_analyzer":{

       "text":"standard"

    }

}

11.9 在线文档及时生成termvector

POST book/english/_termvectors
{
  "doc" : {
    "name" : "hellow word",
    "text" : "twitter test test test"
  },
  "fields": ["name"],
  "per_field_analyzer" : {
    "name":"standard"
  }
}

response

{
  "_index": "book",
  "_type": "english",
  "_version": 0,
  "found": true,
  "took": 1,
  "term_vectors": {
    "name": {
      "field_statistics": {
        "sum_doc_freq": 632,
        "doc_count": 30,
        "sum_ttf": 991
      },
      "terms": {
        "hellow": {
          "term_freq": 1,
          "tokens": [
            {
              "position": 0,
              "start_offset": 0,
              "end_offset": 6
            }
          ]
        },
        "word": {
          "term_freq": 1,
          "tokens": [
            {
              "position": 1,
              "start_offset": 7,
              "end_offset": 11
            }
          ]
        }
      }
    }
  }
}

View Code

11.10 term的统计信息

我们可以根据term的统计信息，过滤出我么想看的统计结果，比如过滤掉一些出现频率过低的term,比如我要过滤出该字段最多只有10个term，而且那些term在该字段中出现的频率为2，且

POST /ecommerce/music/1/_termvectors

{

   "fields":["desc"],
   "offsets":true,
   "payloads":true,
   "positions":true,
   "term_statistics":true,
   "field_statistics" : true,
"filter":{
       "max_num_terms":10, // 返回的最大分词输
       "min_term_freq" : 2, // 忽略低于源文档中出现的次数
       "min_doc_freq" : 1  // 忽略低于所有文档中出现的次数
    }

}

11.11 term过滤参数说明

max_num_terms：每个字段必须返回的最大分词数。默认为25。

min_term_freq：忽略源文档中低于此频率的单词。默认为1。
max_term_freq：忽略源文档中超过此频率的单词。默认为无限制。

min_doc_freq：忽略至少在这么多文档中没有出现的分词。默认为1。
max_doc_freq：忽略超过这么多文档中出现的单词。默认为无限制。

min_word_length：最小字长，低于该字长将被忽略。默认为0。
max_word_length：最大字长，高于该字长将被忽略。默认为unbounded（0）。

官方文档参考：Term Vector Api

12 批量返回分词：Multi termvectors API

采集term信息的方式有两种：index-time(从已经存储的索引中查看) 和 query-time（及时生成）

12.1 index-time

POST /_mtermvectors
{
   "docs": [
      {
         "_index": "twitter",
         "_type": "_doc",
         "_id": "2",
         "term_statistics": true
      },
      {
         "_index": "twitter",
         "_type": "_doc",
         "_id": "1",
         "fields": [
            "message"
         ]
      }
   ]
}

View Code

url中指定索引：

POST /twitter/_mtermvectors
{
   "docs": [
      {
         "_type": "_doc",
         "_id": "2",
         "fields": [
            "message"
         ],
         "term_statistics": true
      },
      {
         "_type": "_doc",
         "_id": "1"
      }
   ]
}

View Code

url中指定索引类型：

POST /twitter/_doc/_mtermvectors
{
   "docs": [
      {
         "_id": "2",
         "fields": [
            "message"
         ],
         "term_statistics": true
      },
      {
         "_id": "1"
      }
   ]
}

View Code

如果索引类型和字段都相同：

POST /twitter/_doc/_mtermvectors
{
    "ids" : ["1", "2"],
    "parameters": {
        "fields": [
                "message"
        ],
        "term_statistics": true
    }
}

View Code

12.2及时批量生成

POST_mtermvectors
{
   "docs": [
      {
         "_index": "book",
         "_type": "english",
         "doc" : {
            "name" : "John Doe",
            "message" : "twitter test test test"
         },
          "fields": ["name"],
          "per_field_analyzer" : {
          "name":"standard"
         }
      },
      {
         "_index": "book",
         "_type": "english",
         "doc" : {
           "name" : "Jane Doe",
           "message" : "Another twitter test ..."
         },
          "fields": ["name"],
          "per_field_analyzer" : {
          "name":"standard"
         }
      }
   ]
}

View Code

response:

{
  "docs": [
    {
      "_index": "book",
      "_type": "english",
      "_version": 0,
      "found": true,
      "took": 2,
      "term_vectors": {
        "name": {
          "field_statistics": {
            "sum_doc_freq": 632,
            "doc_count": 30,
            "sum_ttf": 991
          },
          "terms": {
            "doe": {
              "term_freq": 1,
              "tokens": [
                {
                  "position": 1,
                  "start_offset": 5,
                  "end_offset": 8
                }
              ]
            },
            "john": {
              "term_freq": 1,
              "tokens": [
                {
                  "position": 0,
                  "start_offset": 0,
                  "end_offset": 4
                }
              ]
            }
          }
        }
      }
    },
    {
      "_index": "book",
      "_type": "english",
      "_version": 0,
      "found": true,
      "took": 0,
      "term_vectors": {
        "name": {
          "field_statistics": {
            "sum_doc_freq": 632,
            "doc_count": 30,
            "sum_ttf": 991
          },
          "terms": {
            "doe": {
              "term_freq": 1,
              "tokens": [
                {
                  "position": 1,
                  "start_offset": 5,
                  "end_offset": 8
                }
              ]
            },
            "jane": {
              "term_freq": 1,
              "tokens": [
                {
                  "position": 0,
                  "start_offset": 0,
                  "end_offset": 4
                }
              ]
            }
          }
        }
      }
    }
  ]
}

View Code

12.2.返回该索引全部文档的分词统计

POST book/_search
{  
    "size" : 0, "aggs" : { "messages" : { "terms" : { "size" : 10, "field" : "name" } } } }

官方文档参考：Multi termvectors API

13.?refresh

ES的索引数据是写入到磁盘上的。但这个过程是分阶段实现的，因为IO的操作是比较费时的。

先写到内存中，此时不可搜索
默认经过 1s 之后会(refresh)被写入 lucene 的底层文件 segment 中，此时可以搜索到
flush之后才会写入磁盘

以上过程由于随时可能被中断导致数据丢失，所以每一个过程都会有 translog 记录，如果中间有任何一步失败了，等服务器重启之后就会重试，保证数据写入。translog也是先存在内存里的，然后默认5秒刷一次写到硬盘里。

在 index ，Update , Delete , Bulk 等操作中，可以设置 refresh 的值。取值如下：

`13.1.refresh=true`

更新数据之后，立刻对相关的分片(包括副本) 刷新，这个刷新操作保证了数据更新的结果可以立刻被搜索到。

`13.2.refresh=wait_for`

这个参数表示，刷新后返回。刷新不会立刻进行，而是等待一段时间才刷新 ( index.refresh_interval)，默认时间是 1 秒。刷新时间间隔可以通过index 的配置动态修改。或者直接手动刷新 POST /twitter/_refresh

`13.3.refresh=false`

refresh 的默认值，立即返回。更新数据之后不立刻刷新，在返回结果之后的某个时间点会自动刷新，也就是随机的，看es服务器的运行情况。

那么选择哪种刷新方式？

wait_for 和 true 对比，前者每次会积累一定的工作量再去刷新
true 是低效的，因为每次实时刷新会产生很小的 segment，随后这些零碎的小段会被合并到效率更高的大 segment 中。也就是说使用 true 的代价在于，在 index 阶段会创建这些小的 segment，在搜索的时候也是搜索这些小的 segment，在合并的时候去将小的 segment 合并到大的 segment 中
不要在多个请求中对每一条数据都设置 refresh=wait_for ，用bulk 去批量更新，然后在单个的请求中设置 refresh=wait_for 会好一些
如果 index.refresh_interval: -1 ，将会禁用刷新，那带上了 refresh=wait_for 参数的请求实际上刷新的时间是未知的。如果 index.refresh_interval 的值设置的比默认值( 1s )更小，比如 200 ms，那带上了 refresh=wait_for 参数的请求将很快刷新，但是仍然会产生一些低效的segment。
refresh=wait_for 只会影响到当前需要强制刷新的请求，refresh=true 却会影响正在处理的其他请求。所以如果想尽可能小的缩小影响范围时，应该用 refresh=wait_for

官方文档参考：Refresh api

来源：oschina

链接：https://my.oschina.net/u/4301507/blog/3878185

标签

curl

nes

MultiGet

MinDoc

RedisTemplate常用集合使用说明-opsForHash(四)

被刻印的时光ゝ — Fri, 14 Aug 2020 04:06:47 +0000

RedisTemplate常用集合使用说明-opsForHash(四) 被刻印的时光ゝ 2020-08-14 12:06:47

1、put`(H key,` `HK hashKey,` `HV value)`

新增hashMap值。

redisTemplate.opsForHash().put("hashValue","map1","map1-1");
redisTemplate.opsForHash().put("hashValue","map2","map2-2");

2、values(H key)

获取指定变量中的hashMap值。

List<Object> hashList = redisTemplate.opsForHash().values("hashValue");
System.out.println("通过values(H key)方法获取变量中的hashMap值:" + hashList);

3、entries(H key)

获取变量中的键值对。

Map<Object,Object> map = redisTemplate.opsForHash().entries("hashValue");
System.out.println("通过entries(H key)方法获取变量中的键值对:" + map);

4、get(H key, Object hashKey)

获取变量中的指定map键是否有值,如果存在该map键则获取值，没有则返回null。

Object mapValue = redisTemplate.opsForHash().get("hashValue","map1");
System.out.println("通过get(H key, Object hashKey)方法获取map键的值:" + mapValue);

5、hasKey`(H key,` `Object hashKey)`

判断变量中是否有指定的map键。

boolean hashKeyBoolean = redisTemplate.opsForHash().hasKey("hashValue","map3");
System.out.println("通过hasKey(H key, Object hashKey)方法判断变量中是否存在map键:" + hashKeyBoolean);

6、keys(H key)

获取变量中的键。

Set<Object> keySet = redisTemplate.opsForHash().keys("hashValue");
System.out.println("通过keys(H key)方法获取变量中的键:" + keySet);

7、size(H key)

获取变量的长度。

long hashLength = redisTemplate.opsForHash().size("hashValue");
System.out.println("通过size(H key)方法获取变量的长度:" + hashLength);

8、increment(H key, HK hashKey, double delta)

使变量中的键以double值的大小进行自增长。

double hashIncDouble = redisTemplate.opsForHash().increment("hashInc","map1",3);
System.out.println("通过increment(H key, HK hashKey, double delta)方法使变量中的键以值的大小进行自增长:" + hashIncDouble);

9、increment(H key, HK hashKey, long delta)

使变量中的键以long值的大小进行自增长。

long hashIncLong = redisTemplate.opsForHash().increment("hashInc","map2",6);
System.out.println("通过increment(H key, HK hashKey, long delta)方法使变量中的键以值的大小进行自增长:" + hashIncLong);

10、multiGet`(H key,` `Collection<HK> hashKeys)`

以集合的方式获取变量中的值。

List<Object> list = new ArrayList<Object>();
list.add("map1");
list.add("map2");
List mapValueList = redisTemplate.opsForHash().multiGet("hashValue",list);
System.out.println("通过multiGet(H key, Collection<HK> hashKeys)方法以集合的方式获取变量中的值:"+mapValueList);

11、putAll(H key, Map<? extends HK,? extends HV> m)

以map集合的形式添加键值对。

Map newMap = new HashMap();
newMap.put("map3","map3-3");
newMap.put("map5","map5-5");
redisTemplate.opsForHash().putAll("hashValue",newMap);
map = redisTemplate.opsForHash().entries("hashValue");
System.out.println("通过putAll(H key, Map<? extends HK,? extends HV> m)方法以map集合的形式添加键值对:" + map);

12、putIfAbsent(H key, HK hashKey, HV value)

如果变量值存在，在变量中可以添加不存在的的键值对，如果变量不存在，则新增一个变量，同时将键值对添加到该变量。

redisTemplate.opsForHash().putIfAbsent("hashValue","map6","map6-6");
map = redisTemplate.opsForHash().entries("hashValue");
System.out.println("通过putIfAbsent(H key, HK hashKey, HV value)方法添加不存在于变量中的键值对:" + map);

13、scan(H key, ScanOptions options)

匹配获取键值对，ScanOptions.NONE为获取全部键对，ScanOptions.scanOptions().match("map1").build() 匹配获取键位map1的键值对,不能模糊匹配。

Cursor<Map.Entry<Object,Object>> cursor = redisTemplate.opsForHash().scan("hashValue",ScanOptions.scanOptions().match("map1").build());
//Cursor<Map.Entry<Object,Object>> cursor = redisTemplate.opsForHash().scan("hashValue",ScanOptions.NONE);
while (cursor.hasNext()){
Map.Entry<Object,Object> entry = cursor.next();
System.out.println("通过scan(H key, ScanOptions options)方法获取匹配键值对:" + entry.getKey() + "---->" + entry.getValue());
}

14、delete(H key, Object... hashKeys)

删除变量中的键值对，可以传入多个参数，删除多个键值对。

redisTemplate.opsForHash().delete("hashValue","map1","map2");
map = redisTemplate.opsForHash().entries("hashValue");
System.out.println("通过delete(H key, Object... hashKeys)方法删除变量中的键值对后剩余的:" + map);
（补充）注意：Map集合中put与putIfAbsent的区别

put方法：
```
V put(K key, V value);
```
putIfAbsent方法：
```
V putIfAbsent(K key, V value)；
```
这两种方法都是以key-value键值对的形式存在到map集合中，那么它们两个有什么区别呢？

我们可以从map官网注释中看出：

1.使用put方法添加键值对，如果map集合中没有该key对应的值，则直接添加，并返回null，如果已经存在对应的值，则会覆盖旧值，value为新的值。

2.使用putIfAbsent方法添加键值对，如果map集合中没有该key对应的值，则直接添加，并返回null，如果已经存在对应的值，则依旧为原来的值。

来源：oschina

链接：https://my.oschina.net/botkenni/blog/4476781

标签

Delta

MultiGet

OpenUOM移动性改造-靠新的session iD而不是IP/Port识别客户端

蹲街弑〆低调 — Tue, 04 Aug 2020 09:20:55 +0000

OpenUOM移动性改造-靠新的session iD而不是IP/Port识别客户端蹲街弑〆低调 2020-08-04 17:20:55

写于2014/06/07

设备移动性的挑战

1.设备会经常由于小区或模式切换而更改IP地址。

这种地址更新是移动网络的正常行为，不应作为故障或事故看待，因此理应对应用程序透明，应用不应被此类事件打扰，更无责做善后处理。

2.移动设备存在多张3G/4G/2.75G网卡时，希望这些网卡同时收发数据。

由于这些网卡一般属于不同运营商网络，其网络架构又不同，一般要求数据包携带本运营商网卡的IP地址作为源(这一般是为了在该运营商核心网终点处做NAT)，因此为了支持多运营商多网卡负载均衡，一个应用程序业务流数据包必然要支持不同的IP地址作为源，不幸的是，即便对于UDP而言，大多数应用也都是只支持单一源(它们会针对UDP socket调bind)，以减少服务端的复杂性。

3.经常性的失联

电梯里，高铁上，山区景点盲区，公司的厕所...你会突然失联，然后突然出现！但是应用程序却不希望受到如此的折腾，对于OpenUOM而言，经过测试，一次重连大约要5秒时间，代价是高昂的，重新TLS握手，重新push，...实际上只要你的ping-restart时间足够小，对于信号缺失就会很迅速的被OpenUOM感知，解决方案就是将ping-restart放大，可是你也不知道自己失联多久。

4.RRC相关造成的额外延时

有时候，即便你处在信号很好的地方，也会发现打开一个网页非常慢，然后迅速就会变快，这其实是移动网络的本质，为了节省电量损耗，设备并不是一直和网络保持连接的，而是运行一种和Linux的NOHZ算法一样的机制，在设备长时间没有数据收发的时候，关闭连接，和Linux的NOHZ不同的是，NOHZ状态的脱离时间是明确的，它由下一个timer到期的时间以及时钟之外的任何中断的最小值决定，但是RRC机制却不同，数据什么时候会发送完全取决于神一样的用户，因此当有数据要发送的时候，必须重新接入移动网，协商参数等等，这无疑会消耗时间。这个抖动不是用户应用能解决的，因为这取决于设备厂商的实现以及移动网络的规范，这是一个纯粹的网络问题，因此本文不会涉及过多这方面的内容。

会话层真的太重要了

鉴于TCP/IP栈的抢先进化，其对手便永远失去了机会，因此应用程序一般都是直接接口在传输层协议之上，这是事实！

对于应用开发接口，应用程序的数据收发直接基于一个INET socket，而一个socket的“连接”通过五元组来标识，因此五元组的任何一个元素改变，或者说网络的任何一个事件都会影响到这个对应的socket，socket I/O接口的手册中明确给出了返回值和错误码，而直接调用这些接口的应用程序必须处理这种错误，因此网络事件便直接影响了应用程序！

但是网络事件不应影响应用，比如网络断了不一定让应用程序必须采取善后和重连，也许这只是暂时事件，比如IP地址变了。应用程序要做的就是生成业务数据并发送，它并不需要直接从socket接口获取并处理错误码。应用程序只需要知道发送数据发出了多少即可，即便真有严重事件需要彻底退出，也不该是来自TCP/IP的通知。那么一定需要一个新的层，历史缘故，我称它会话层吧。

OpenUOM的故事

我希望OpenUOM的处理层完全和网络状态脱离，即使客户端的IP地址变了，也能用新的IP地址继续和服务端通信，即使信号全无，一旦有了信号，通信继续进行，也就是说，网络状态不会打扰到OpenUOM进程的处理。为了一步步地满足这个需求，我们看一下OpenUOM目前的行为，两端连通以后，我试着改变客户端的IP地址，结果服务端报错：

Wed Jan 1 00:58:46 2014 us=439027 GET INST BY VIRT: 0e:fe:bc:a3:6f:fe -> zhaoya/192.168.1.197:33512 via 0e:fe:bc:a3:6f:fe
Wed Jan 1 00:58:46 2014 us=439981 zhaoya/192.168.42.197:33512 UDPv4 WRITE [133] to 192.168.1.197:33512: P_DATA_V1 kid=0 DATA len=132
Wed Jan 1 00:58:46 2014 us=822941 TLS State Error: No TLS state for client 192.168.1.199:33512, opcode=6
Wed Jan 1 00:58:46 2014 us=823912 GET INST BY REAL: 192.168.1.199:33512 [failed]
Wed Jan 1 00:58:47 2014 us=197871 MULTI: REAP range 128 -> 144
Wed Jan 1 00:58:47 2014 us=198861 TLS State Error: No TLS state for client 192.168.1.199:33512, opcode=6
Wed Jan 1 00:58:47 2014 us=198887 GET INST BY REAL: 192.168.1.199:33512 [failed]
...上述原则上将陌生的IP/Port看成了新的TLS session，但是OpenUOM的TLS握手和网络根本就没有关系。它是在BIO上完成的TLS，用Reliable层保证了传输过程的可靠性。但是原谅这个报错吧，代码的初衷可能是防止Dos攻击而不是别的，因为如果没有经过成功的TLS握手，那么一个连接是不可能正常插进来的，否则TLS就该废掉了。现在着手自己的实现。思路是很清晰的，只是在OpenUOM的协议头里面增加一个字段：session ID，服务端用这个session ID识别和区别不同的客户端，不再基于客户端的IP/Port来识别和区别不同的客户端，这样的话，只要客户端发出的OpenUOM的数据包被服务端收到了，且解析出来的session ID可以对应到一个multi_instance，那么这个数据包就是合法的。
因此，OpenUOM的数据收发和底层的网络状态彻底隔离了，只要用OpenUOM协议构造数据包即可，如果网络状况不好，那就发不出去，但是只要网络恢复，就可以发出去，只要发出去被服务端收到，就能识别和解析并对应到某个multi_instance，如果客户端IP地址变化了，只要保持到服务端IP地址的可达性，数据就能发送到服务端，只要能到服务端，服务端就能从OpenUOM协议包中解析出session ID，从而对应到一个multi_instance。
思路有了，也很清晰，那么怎么改呢？

解决问题的步骤

写这篇文章并不是为了表达OpenUOM这个程序如何被用在移动设备上，这个可以写上一本书，本文的主要目的是想展示一种解决问题的方式，我在有了上面的思路后是如何验证其确实可行的呢？我并没有一头扎进那沸腾的代码，去实现最终的方案，比如直接就去修改OpenUOM的协议，而是先将代码写死，瞬间得到一个行或者不行的结论。这个过程要修改最少的代码！为了找到修改何处，还得从上面的报错入手。其在ssl.c的tls_pre_decrypt_lite函数报错，该函数没有任何关于multi_instance的信息，因此我知道在这个tls_pre_decrypt_lite函数调用之前，程序已经进入异常流了，因此就找tls_pre_decrypt_lite的调用代码，在mudp.c中的multi_get_create_instance_udp找到了：

struct multi_instance *
multi_get_create_instance_udp (struct multi_context *m)
{
    ...
    if (mroute_extract_openuom_sockaddr (&real, &m->top.c2.from.dest, true)) {
        struct hash_element *he;
        const uint32_t hv = hash_value (hash, &real);
        struct hash_bucket *bucket = hash_bucket (hash, hv);
 
        hash_bucket_lock (bucket);
        he = hash_lookup_fast (hash, bucket, &real, hv);

        if (he) {
            mi = (struct multi_instance *) he->value;
        } else {
            // 找不到multi_instance的异常流处理
            if (!m->top.c2.tls_auth_standalone
                 || tls_pre_decrypt_lite (m->top.c2.tls_auth_standalone, &m->top.c2.from, &m->top.c2.buf)) {
                // 异常流处理
            }
        }
...
}

关键是multi_instance没有找到，为什么呢？我发现mroute_extract_openuom_sockaddr的传入参数real，正是根据接收到的数据包的来源IP和端口初始化的，接下来查询multi_instance哈希表的时候，这个real就是key的值，在客户端的IP地址改变了之后，当然找不到任何value了，就算找到也是冲突链的value，最终返回的为NULL！接下来是关键点，既然是查询哈希表没有查到，并且是由于数据包的源IP/Port改变了没有找到，那么就忽略掉这个查询key，即想办法让这个查询百分百可以找到结果。这个思想是快速解决问题的关键，正是由于找不到key对应的value才失败，如果key能找到value的话要是能成功，问题就转化为了如何让key找到value而这我们已经有办法了，即从buffer里面取key，实际上这是另一个问题，这难道不是一次深刻的执果索因之旅吗？我在高中的物理竞赛中用此法获得了，唉，不提当年勇！这个思想很简单，但用的人不多，很多人都是一开始就修改OpenUOM协议，然后到最后一起调试，对于设计方案通过的研发任务，这是常规做法，但对于预研或极限开发来讲，这万万要不得！你根本就不知道自己的想法在OpenUOM既有框架内是否行得通，怎能一开始就大段改代码呢？R&D没有写成RD是因为它们实际上不是一个部门，起码员工解决问题的思路是不同的，R部门侧重因果推导， 执果索因，可行性验证，测试，D部门侧重设计，代码质量，进度控制，项目管理以及各种模型(迭代瀑布...)。

因此就重新定义hash_function以及hash_compare，让其返回定值！背后的思想是固定了hash key和hash compare结果之后，如果此时改变了客户端IP地址而依然不出错，就说明hash查找的过程已经和收到数据包的源IP地址和端口没有关系了，剩下的就是将这个hash key从固定值改为从收到的OpenUOM数据的协议头里面取就可以了。我的新版hash函数如下：

m->hash = hash_init (t->options.real_hash_size,
               fake_addr_hash_function,
               fake_addr_compare_function);

其中：

uint32_t fake_addr_hash_function(const void *key, uint32_t iv)
{
    return 0x10101010;
}
bool fake_addr_compare_function(const void *key1, const void *key2)
{
    return true;
}

就改这些即可！服务端已经可以将客户端对应到唯一的那个multi_instance了，并且成功解析封装后的IP报文，可是发现服务端往客户端返回的时候没有通过，我通过192.168.1.199接入OpenUOM成功，然后将OpenUOM客户端的地址改为了192.168.1.197，OpenUOM客户端所在机器长ping服务端的虚拟IP地址，服务端日志打印如下：
Wed Jan 1 00:02:11 2014 us=389812 zhaoya/192.168.1.199:38310 UDPv4 WRITE [77] to 192.168.1.199:38310: P_DATA_V1 kid=0 DATA len=76
发现写入的目标地址还是192.168.1.199，为何没有切换到我新改的地址？我觉得这是一个小问题。我只要找到打印上面日志的位置就好，而这很简单，代码在forward.c的process_outgoing_link函数中，注意以下的代码：

ASSERT (link_socket_actual_defined (c->c2.to_link_addr));

可见，这个to_link_addr是关键，这个值是OpenUOM客户端接入的时候生成的，以后不会变化，我只要将其改为实时更新的即可，就是说，无条件使用上次数据包的from地址，这些都在context_2结构体：

struct context_2
{
...
  struct link_socket_actual *to_link_addr;    /* IP address of remote */
  struct link_socket_actual from;               /* address of incoming datagram */
...
}

注释很清晰！怎么改呢？可以将使用to_link_addr的地方全部使用&from，当然我不会这么做，因为这只是一个可行性证实，不是正儿八经的改代码，如此鲁莽是不对的，我的做法是添加一段临时代码：

void
process_outgoing_link (struct context *c)
{
  struct gc_arena gc = gc_new ();

  perf_push (PERF_PROC_OUT_LINK);
#if 1    // 吐嘈时骂过的，实际上我经常这么玩
{
        c->c2.to_link_addr = &c->c2.from;
}
#endif
...
}

至此，我认为当初的想法是可行的。事后，我试着在OpenUOM的协议中增加了一个32位的session ID，然后彻底更改了hash function，传入的key就是从BPTR(buf)中取出的这个session ID，并且我把OpenUOM客户端的数量增加到了3个，同样是一致的结果，时间定在了晚上1点35分。如果这是一个下雨的夜晚，我可能会做更多的修改，但是这是一个燥热的初夏之夜！

修改OpenUOM以适应移动性这个想法是我突然想到的，由于近期工作基本和网络无关，且比较杂乱又有严格deadline，我也就不能在工作时间有那么多的闲情雅致，只能选一个下雨的夜晚来折腾。可是雨到底也没来，我也就只能做个半拉子，还有哪些方面没做呢？难道上面说的不就是全部吗？不是全部，很多细节都没有处理，比如客户端改变IP地址后服务端要即使更新该客户端对应的multi_instance中相关数据结构，比如echo机制的ping替换各发各自的ping机制，另外各种restart重连机制也要被替换，移动环境中，很多在非移动环境中发生的导致应用必须重连重置的网络事件都是正常的，因此必须最少化重连重置操作，需要做的就两件事，一是继续发送，二是等！

关于本文的引申

不能杜绝问题的发生，那就忽略掉问题，使其对自身毫无影响。多加一个层就可以隔离问题！你不能让天公不下雨，但你能带上伞或穿上雨衣雨鞋，或者将活动改在室内，再或者像我这样，尽情雨中欢呼...如果你为了不下雨而去研究大气运行原理，研究让云层散开的炮弹，那你就走偏了，虽然最终你可能会成为伟大科学家，但目前，你可能只是因为下雨影响了你的心情，而已。
在定位问题的过程中，千万不要过早扎入代码细节，用最快的方式验证可行性和合理性。然后再细嚼慢咽，要分清主要问题和次要问题，主要问题简化其本质，次要问题模拟其现象，不应该为次要问题浪费大量时间和精力。你不可能一次搞定所有问题，学会模拟当前非本质问题造成的现象是一种技巧技能，能从简化环境中得到真实结论是一种推理技能。

我举一个我早年的反例子。有一次因为文件写入出错，搞了我一个多礼拜没搞定，最终也没搞定，但是却学会了ext2文件系统的数据恢复，八杆子打不着的一个问题，而且不是用debugfs实现，是自己编程哦！对个人好奇心而言，我没什么损失，可是却耽误了进度，其实最可悲的是那些不是好奇心使然的coder，迷迷糊糊就到了内核驱动，然后一无所获或者鼻青脸肿出来...

要问我为何喜欢雨天，也许它能将飘忽在天

来源：oschina

链接：https://my.oschina.net/u/4376383/blog/4332126

标签

redis 大key 问题

空扰寡人 — Tue, 28 Jul 2020 16:51:26 +0000

redis 大key 问题空扰寡人 2020-07-29 00:51:26

命令：redis-cli ******* --bigkeys

redis-cli --bigkeys的优点是可以在线扫描，不阻塞服务；缺点是信息较少，内容不够精确。扫描结果中只有string类型是以字节长度为衡量标准的。List、set、zset等都是以元素个数作为衡量标准，元素个数多不能说明占用内存就一定多

处理方法：

由于redis是单线程运行的，如果一次操作的value很大会对整个redis的响应时间造成负面影响，所以业务上通常会以以下方式进行分拆。

分拆

单个key存储大value

每次都是整存整取

这种操作一般都是每次整存整取，这种情况可以尝试将对象拆分成多个key-value，使用multiGet获取值，这样分拆意义在于分拆操作的压力，将操作压力平摊到多个redis实例，降低对于单个redis的io压力。

每次只存取部分数据

同样可以拆成几个key-value，也可以将这些存储在一个hash中，每个field代表具体属性，使用hget，hmget来获取部分value，使用hset，hmset来更新部分属性。

hash，set，zset，list中存储过多数据

同样可以将这部分元素拆分，以hash为例，正常的流程是：hget(hashKey, field)；hset(hashKey, field, value)。现在可以固定一个桶数量，比如1w，每次存取的时候，先在本地计算field的hash值，对1w取模，确定field落在哪个key上。

newHashKey = hashKey + ( hash(field) % 10000）; hset (newHashKey, field, value) ; hget(newHashKey, field)

set，zset，list做法类似。

一个集群存储了上亿的key

如果key个数过多会带来更多的内存占用空间：

key本身占用。
集群中，服务端会建立slot2key的映射关系，这种指针占用在key多的情况下存在巨大的空间浪费，在key上亿时，内存消耗十分明显。

减少key个数可以减少对内存的消耗，可以参考hash结构存储，将多个key存储在一个hash结构中。

组合那些key本身强相关性的，比如key代表一个对象，m每个key是对象的一个属性，按照这种方式设置一个新的key-hash的结构，原先的key作为这个新hash field。

比如：

将user.zhangsan.id= 123，user.zhangsan.age = 18，user.zhangsan.country = china 改成 key = user.zhangsan field:id = 123 field:age = 18 field:country = china

如果key本身没有相关性，可以预估总量，对一些场景预分固定的桶数量。

比如有2亿key，按照一个hash存储100个field来算，需要200w个桶，这样可以按照200w个固定桶数量做取模，hash(123456) % 200w，比如算出3个key的桶分别是1，2，3。调用存储api hset(key, field, value)，读取时用hget(key,field)。建议分桶数量100合适。

Bitmap和Bloom拆分

使用Bloom的场景往往是数据量极大的情况，这种情况下，bitmap和bloom使用空间比较大。

如果bitmap比较大，可以拆分成多个小的bitmap，可以通过结合hash方式，将key路由到hash上对应的bitmap上，将不同的key分配给不同的bitmap，而不是所有小的bitmap当作一个整体，这样每次请求都只要取redis中的一个key即可。

来源：oschina

链接：https://my.oschina.net/shunshun/blog/4411426

标签

redis-cli

Redis

MultiGet

search（6）- elastic4s-CRUD

♀尐吖头ヾ — Wed, 22 Apr 2020 23:18:02 +0000

search（6）- elastic4s-CRUD ♀尐吖头ヾ 2020-04-23 07:18:02

如果我们把ES作为某种数据库来使用的话，必须熟练掌握ES的CRUD操作。在这之前先更正一下上篇中关于检查索引是否存在的方法：elastic4s的具体调用如下：

  //删除索引
  val rspExists = client.execute(indexExists("company")).await
  if (rspExists.result.exists)
     client.execute(deleteIndex("company")).await

在下面我们还会示范如何检查一条记录（document）是否存在的方法。

先示范新建一条记录。一般来讲数据库表都有个唯一字段，最好用ES里的id来代表，否则ES会自动产生一个唯一id，那么随机读取get时就会很不方便。如果新插入的记录id已经在表里存在，ES会替换新的内容，不会产生异常。可以在elastic4s里使用createOnly(true)来强制产生重复id异常：

import com.sksamuel.elastic4s.{ElasticClient, ElasticProperties}
import com.sksamuel.elastic4s.akka._
import akka.actor._

import scala.concurrent.ExecutionContext.Implicits.global
object Lesson05 extends App {
  import com.sksamuel.elastic4s.ElasticDsl._

  private implicit lazy val system: ActorSystem = ActorSystem()
  val akkaClient = AkkaHttpClient(AkkaHttpClientSettings(List("130.1.1.234:9200")))
  val client = ElasticClient(akkaClient)

  val publisher = indexInto("company").id("c00001")
    .fields(
      "code" -> "c00001",
      "name" -> "人民出版社",
      "biztype" -> "出版社",
      "addr" -> Map(
        "district" -> "北京市东城区",
        "address" -> "朝阳门内大街166号"
      ),
      "regdate" -> "1963-02-18",
      "contact" -> "65122634@163.com"
    ).createOnly(true)

  val pubExists = client.execute(exists("company","c00001")).await
  if (pubExists.isSuccess) {
    val createPub = client.execute(publisher).await

    if (createPub.isSuccess) {
      val pub = client.execute(get("company", "c00001").fetchSourceContext(true)).await
      println(s"${pub.result.sourceAsMap}")
    } else println(s"${createPub.error.reason}")
  } else println(s"${pubExists.error.reason}")

  val dstributor = indexInto("company").id("c00002")
    .fields(
      "code" -> "c00002",
      "name" -> "新华文轩出版传媒股份有限公司",
      "biztype" -> "出版发行",
      "addr" -> Map(
        "district" -> "四川省成都市锦江区",
        "address" -> "金石路239号4栋1层1号"
      ),
      "regdate" -> "2005-03-09",
      "contact" -> "52635286@qq.com"
    ).createOnly(true)

  val grpExists = client.execute(exists("company","c00002")).await
  if (grpExists.isSuccess) {
    val createGroup = client.execute(dstributor).await

    if (createGroup.isSuccess) {
      val dstr = client.execute(get("company", "c00002").fetchSourceContext(true)).await
      println(s"${dstr.result.sourceAsMap}")
    } else println(s"${createGroup.error.reason}")
  } else println(s"${grpExists.error.reason}")

  val mget = client.execute(multiget(
    get("company","c00001"),
    get("company","c00002")
  )).await
  if(mget.isSuccess)
    mget.result.items.foreach(i => println(s"${i.sourceAsMap}"))
  else println(s"${mget.error.reason}")

  scala.io.StdIn.readLine()
  system.terminate()
  client.close()
}

上面示范了不同类型字段的填写方式，特别是nested字段如addr。每插入一条新记录就用get进行一次验证，输出显示：

HashMap(name -> 人民出版社, regdate -> 1963-02-18, contact -> 65122634@163.com, code -> c00001, addr -> Map(district -> 北京市东城区, address -> 朝阳门内大街166号), biztype -> 出版社)
HashMap(name -> 新华文轩出版传媒股份有限公司, regdate -> 2005-03-09, contact -> 52635286@qq.com, code -> c00002, addr -> Map(district -> 四川省成都市锦江区, address -> 金石路239号4栋1层1号), biztype -> 出版发行)
HashMap(name -> 人民出版社, regdate -> 1963-02-18, contact -> 65122634@163.com, code -> c00001, addr -> Map(district -> 北京市东城区, address -> 朝阳门内大街166号), biztype -> 出版社)
HashMap(name -> 新华文轩出版传媒股份有限公司, regdate -> 2005-03-09, contact -> 52635286@qq.com, code -> c00002, addr -> Map(district -> 四川省成都市锦江区, address -> 金石路239号4栋1层1号), biztype -> 出版发行)

上面提到过，如果我们想把ES当作普通的数据库来使用的话，还是要备齐了CRUD功能。具体操作按照关系数据库方式围绕着唯一键id进行。比如，我们可以用id来检查记录是否已经存在：

  val pubExists = client.execute(exists("company","c00001")).await
  if (pubExists.isSuccess) {...}

上面我们示范了针对索引的create,read操作。下面讨论一下update：update 可分单笔或批次两类，分别为：updateById, updateByQuery，很明显：updateByQuery是以query作为目标筛选条件的成批update操作。与上面的create操作一样，我们还是需要考虑唯一键id，这个可以在updateById操作里处理：当目标id存在时，用update请求里的字段值更新对应的字段。如目标id不存在的话就把update请求里的字段值当作新记录内容插入：

import com.sksamuel.elastic4s.http.JavaClient
import com.sksamuel.elastic4s.requests.common.RefreshPolicy
import com.sksamuel.elastic4s.{ElasticClient, ElasticProperties}
import scala.concurrent.ExecutionContext.Implicits.global
object Lesson06 extends App {
  import com.sksamuel.elastic4s.ElasticDsl._

  val esjava = JavaClient(ElasticProperties("http://localhost:9200"))
  val client = ElasticClient(esjava)

  val doc1 = updateById("company","t00001")
      .docAsUpsert(
        Map(
          "code" -> "t00001",
          "name" -> "test company1"
        )
      )

  val doc2 = updateById("company","t00002")
    .docAsUpsert(
      Map(
        "code" -> "t00002",
        "name" -> "test company2"
      )
    )

  val doc3 = updateById("company","t00003")
    .docAsUpsert(
      Map(
        "code" -> "t00003",
        "name" -> "test company3"
      )
    )

  val updateAll = for {
    _ <- client.execute(doc1)
    _ <- client.execute(doc2)
    _ <- client.execute(doc3)
  } yield()
  updateAll.await

  val getResults = client.execute(multiget(
     get("company","t00001").fetchSourceInclude("code","name"),
     get("company","t00002").fetchSourceInclude("code","name"),
     get("company","t00003").fetchSourceInclude("code","name")
   )
  ).await

  getResults.result.items.foreach(i => println(i.sourceAsMap))

  client.close()
}

成批更新比较麻烦，因为通常每条记录的更新都可能涉及到当前记录的字段值，或作为判断条件，或为更新值，我们需要使用并处理当前记录中某些字段。这就需要在数据层面运行某些计算方法，可以用脚本语言来实现这样的功能，如下：

  import com.sksamuel.elastic4s.requests.script.Script
  val script = "ctx._source.fullname = ctx._source.code+' '+ctx._source.name"
  val updateByQ = updateIn("company")
    .query(matchQuery("name","test"))
    .script(Script(script,Some("painless")))

  val qupResult = client.execute(updateByQ).await

  val getResults = client.execute(multiget(
     get("company","t00001"),
     get("company","t00002"),
     get("company","t00003")
   )
  ).await

  getResults.result.items.foreach(i => println(i.sourceAsMap))

与update一样，delete也分单个或成批删除模式。delete by Id 示例如下：

  (for {
    _ <- client.execute(delete("t00001").from("company"))
    _ <- client.execute(deleteByQuery("company", "t00002"))
  } yield()).await

delete by Query 用法如下：

  import com.sksamuel.elastic4s.Index._
  client.execute(
    deleteByQuery(toIndex("company"),
      termQuery("code","t00003"))
  ).await

来源：oschina

链接：https://my.oschina.net/u/4409432/blog/3300552

标签

search（6）- elastic4s-CRUD

扶醉桌前 — Wed, 22 Apr 2020 21:05:08 +0000

search（6）- elastic4s-CRUD 扶醉桌前 2020-04-23 05:05:08

  //删除索引
  val rspExists = client.execute(indexExists("company")).await
  if (rspExists.result.exists)
     client.execute(deleteIndex("company")).await

在下面我们还会示范如何检查一条记录（document）是否存在的方法。

import com.sksamuel.elastic4s.{ElasticClient, ElasticProperties}
import com.sksamuel.elastic4s.akka._
import akka.actor._

import scala.concurrent.ExecutionContext.Implicits.global
object Lesson05 extends App {
  import com.sksamuel.elastic4s.ElasticDsl._

  private implicit lazy val system: ActorSystem = ActorSystem()
  val akkaClient = AkkaHttpClient(AkkaHttpClientSettings(List("130.1.1.234:9200")))
  val client = ElasticClient(akkaClient)

  val publisher = indexInto("company").id("c00001")
    .fields(
      "code" -> "c00001",
      "name" -> "人民出版社",
      "biztype" -> "出版社",
      "addr" -> Map(
        "district" -> "北京市东城区",
        "address" -> "朝阳门内大街166号"
      ),
      "regdate" -> "1963-02-18",
      "contact" -> "65122634@163.com"
    ).createOnly(true)

  val pubExists = client.execute(exists("company","c00001")).await
  if (pubExists.isSuccess) {
    val createPub = client.execute(publisher).await

    if (createPub.isSuccess) {
      val pub = client.execute(get("company", "c00001").fetchSourceContext(true)).await
      println(s"${pub.result.sourceAsMap}")
    } else println(s"${createPub.error.reason}")
  } else println(s"${pubExists.error.reason}")

  val dstributor = indexInto("company").id("c00002")
    .fields(
      "code" -> "c00002",
      "name" -> "新华文轩出版传媒股份有限公司",
      "biztype" -> "出版发行",
      "addr" -> Map(
        "district" -> "四川省成都市锦江区",
        "address" -> "金石路239号4栋1层1号"
      ),
      "regdate" -> "2005-03-09",
      "contact" -> "52635286@qq.com"
    ).createOnly(true)

  val grpExists = client.execute(exists("company","c00002")).await
  if (grpExists.isSuccess) {
    val createGroup = client.execute(dstributor).await

    if (createGroup.isSuccess) {
      val dstr = client.execute(get("company", "c00002").fetchSourceContext(true)).await
      println(s"${dstr.result.sourceAsMap}")
    } else println(s"${createGroup.error.reason}")
  } else println(s"${grpExists.error.reason}")

  val mget = client.execute(multiget(
    get("company","c00001"),
    get("company","c00002")
  )).await
  if(mget.isSuccess)
    mget.result.items.foreach(i => println(s"${i.sourceAsMap}"))
  else println(s"${mget.error.reason}")

  scala.io.StdIn.readLine()
  system.terminate()
  client.close()
}

上面示范了不同类型字段的填写方式，特别是nested字段如addr。每插入一条新记录就用get进行一次验证，输出显示：

HashMap(name -> 人民出版社, regdate -> 1963-02-18, contact -> 65122634@163.com, code -> c00001, addr -> Map(district -> 北京市东城区, address -> 朝阳门内大街166号), biztype -> 出版社)
HashMap(name -> 新华文轩出版传媒股份有限公司, regdate -> 2005-03-09, contact -> 52635286@qq.com, code -> c00002, addr -> Map(district -> 四川省成都市锦江区, address -> 金石路239号4栋1层1号), biztype -> 出版发行)
HashMap(name -> 人民出版社, regdate -> 1963-02-18, contact -> 65122634@163.com, code -> c00001, addr -> Map(district -> 北京市东城区, address -> 朝阳门内大街166号), biztype -> 出版社)
HashMap(name -> 新华文轩出版传媒股份有限公司, regdate -> 2005-03-09, contact -> 52635286@qq.com, code -> c00002, addr -> Map(district -> 四川省成都市锦江区, address -> 金石路239号4栋1层1号), biztype -> 出版发行)

  val pubExists = client.execute(exists("company","c00001")).await
  if (pubExists.isSuccess) {...}

import com.sksamuel.elastic4s.http.JavaClient
import com.sksamuel.elastic4s.requests.common.RefreshPolicy
import com.sksamuel.elastic4s.{ElasticClient, ElasticProperties}
import scala.concurrent.ExecutionContext.Implicits.global
object Lesson06 extends App {
  import com.sksamuel.elastic4s.ElasticDsl._

  val esjava = JavaClient(ElasticProperties("http://localhost:9200"))
  val client = ElasticClient(esjava)

  val doc1 = updateById("company","t00001")
      .docAsUpsert(
        Map(
          "code" -> "t00001",
          "name" -> "test company1"
        )
      )

  val doc2 = updateById("company","t00002")
    .docAsUpsert(
      Map(
        "code" -> "t00002",
        "name" -> "test company2"
      )
    )

  val doc3 = updateById("company","t00003")
    .docAsUpsert(
      Map(
        "code" -> "t00003",
        "name" -> "test company3"
      )
    )

  val updateAll = for {
    _ <- client.execute(doc1)
    _ <- client.execute(doc2)
    _ <- client.execute(doc3)
  } yield()
  updateAll.await

  val getResults = client.execute(multiget(
     get("company","t00001").fetchSourceInclude("code","name"),
     get("company","t00002").fetchSourceInclude("code","name"),
     get("company","t00003").fetchSourceInclude("code","name")
   )
  ).await

  getResults.result.items.foreach(i => println(i.sourceAsMap))

  client.close()
}

  import com.sksamuel.elastic4s.requests.script.Script
  val script = "ctx._source.fullname = ctx._source.code+' '+ctx._source.name"
  val updateByQ = updateIn("company")
    .query(matchQuery("name","test"))
    .script(Script(script,Some("painless")))

  val qupResult = client.execute(updateByQ).await

  val getResults = client.execute(multiget(
     get("company","t00001"),
     get("company","t00002"),
     get("company","t00003")
   )
  ).await

  getResults.result.items.foreach(i => println(i.sourceAsMap))

与update一样，delete也分单个或成批删除模式。delete by Id 示例如下：

  (for {
    _ <- client.execute(delete("t00001").from("company"))
    _ <- client.execute(deleteByQuery("company", "t00002"))
  } yield()).await

delete by Query 用法如下：

  import com.sksamuel.elastic4s.Index._
  client.execute(
    deleteByQuery(toIndex("company"),
      termQuery("code","t00003"))
  ).await

来源：oschina

链接：https://my.oschina.net/u/4312361/blog/3301102

标签

[转帖]RocksDB简介

人盡茶涼 — Fri, 17 Apr 2020 00:25:31 +0000

[转帖]RocksDB简介人盡茶涼 2020-04-17 08:25:31

【推荐阅读】微服务还能火多久？>>>

RocksDB简介

https://www.jianshu.com/p/a0088d7e9b97

1、RocksDB简介

RocksDB项目起源于Facebook的一个实验项目,该项目旨在开发一个与快速存储器（尤其是闪存）存储数据性能相当的数据库软件，以应对高负载服务。
这是一个c++库,可用于存储键和值,可以是任意大小的字节流。它支持原子读和写。
RocksDB具有高度灵活的配置功能,可以通过配置使其运行在各种各样的生产环境,包括纯内存,Flash,硬盘或HDFS。它支持各种压缩算法，并提供了便捷的生产环境维护和调试工具。

2、假设和目标

性能:

RocksDB的主要设计目标是保证存取快速存储器和高负载服务器更高效，保证充分利用Flash或RAM子系统提供的高速率读写，支持高效的查找和范围scan，支持高负载的随机读、高负载的更新操作或两者的结合。其架构应该支持高并发读写和容量大增时系统的一致性。

向后兼容性:

这个软件的新版本应该是向后兼容的,因此,当升级到新版本时现有的应用程序不需要改变。

3、高级体系结构

RocksDB是一个嵌入式键值存储器，其中键和值是任意的字节流。RocksDB中的所有数据是按序存放的。常见操作包括Get(key), Put(key), Delete(key) and Scan(key)。
RocksDB有三个基本结构：RocksDB memtable,sstfile和logfile。memtable是一个内存数据结构——新数据会插入到memtable和日志文件（可选）。日志文件是顺序写入的，位于磁盘。当memtable写满后,数据会被刷新到磁盘上的sstfile文件，同时相应的日志文件可以安全地删除。sstfile中的数据经过排序的,目的是为了加快键查找。

4、特性

Gets,迭代器和快照

键和值被视为纯字节流，没有大小的限制。
Get接口允许应用程序从数据库中获取一个键值。MultiGet接口允许应用程序从数据库中检索多个键值。MultiGet接口返回的key-value对都是相互匹配的。所有数据库中的数据都按顺序存放。应用程序可以指定一个key比较方法来定义key的排序顺序。迭代器允许应用程序对数据库进行RangeScan。
迭代器可以先定位一个指定的键,然后应用程序就可以从这个定位点开始一个一个扫描key。迭代器还可以用来对key做反向迭代。创建迭代器是会创建当前数据库的一个快照视图，因此,通过迭代器返回的所有键都来自同一个数据库视图。
Snapshot允许应用程序创建一个快照视图。Get和迭代器可以从一个指定的快照读取数据。在某种意义上,Snapshot和迭代器都提供了某个时间点上数据库的快照视图,但两者的实现是不同的。
短暂的扫描最好通过迭代器而耗时较长的扫描最好通过快照。迭代器记录了数据库当前视图对应文件，直到迭代器被释放才删除这些。而快照并不能阻止文件删除;相反,compaction流程知道当前的快照并且不会删除任何现有快照中的key。数据库重启后，快照将丢失。重载RocksDB(通过服务器重启)会释放所有先前的快照。

前缀迭代器

大多数LSM引擎无法支持一个高效RangeScan,因为它需要查找每一个数据文件。但大多数应用程序不会对key进行随机扫描,而更多的是扫描给定前缀的key。
RocksDB利用了这种优势。应用程序可以通过prefix_extractor指定一个key的前缀。RocksDB用此来保存每个key前缀的bloom，指定了前缀(通过ReadOptions)
的迭代器将使用bloom二进制位来避免查找不包含指定key前缀的文件。

更新

Put操作向数据库插入单个key-value。如果键已经存在,旧值将被覆盖。Writer操作允许将多个keys-values原子地插入到数据库中。数据库保证同一个Writer操作
中的所有keys-values要么全部插入，要么都不插入。如果其中任何一个键已经存在于数据库中,旧值将被覆盖。

持久性

Put操作数据会存储在内存中的缓冲区称为memtable，也会选择性地插入到事务日志。每一个Put操作都有一组标志(通过WriteOptions设置),这些标志指定Put操作数据是否应该插入到事务日志。WriteOptions也可以指定在put操作提交前一个同步调用是否写入事务日志。在内部,RocksDB使用batch-commit机制批量写入事务日志,这样它可以使用一个同步调用提交多个事务。

容错

RocksDB使用校验和检测数据是否正确。每个块(通常是4k到128k大小)都有自己的校验和。一块数据一旦写入将不会修改。RocksDB通过硬件支持动态获取校验和的计算结果，以避免需要是自己计算校验和。

多线程Compaction

Compactions可以删除同一key的多个副本,副本是应用程序覆盖现有key是产生的，可以删除key。通过配置可以让Compaction以多线程方式运行。
LSM的写数据的整体吞吐量直接取决于Compaction的速度,特别是当数据存储在SSD或RAM这种存储器中。RocksDB可以处理多个线程并发的Comopaction请求。多线程Compaction场景下写数据的速率比单线程场景下的速率快10倍。
整个数据库存储在一组sstfiles。memtable写满时,它的内容会被写入Level-0层的一个文件中，在此过程中，重复和被覆盖的key会被删除。
一些文件被定期压缩合并形成更大的文件——这就是所谓的compaction。
RocksDB支持两种不同形式的compaction。普遍的做法是将所有文件按时间顺序保存在L0。compaction选择几个彼此相邻的文件并将它们合并成一个新文件L0。所有文件可以有重叠的key。分层形式的compaction将数据存储在数据库中的多个层中。最新的数据存储在L0和最旧的数据存储在Lmax。L0层中的文件可以有重叠的key,但其他层中文件的key不能重叠。一次compaction过程就是选择Ln层的一个文件及它在Ln+1层的所有重叠文件进行压缩合并形成Ln+1层的新文件。相比层形式的compaction方法，普遍的compaction方法写数据性能较低，但空间利用率较高。
MANIFEST文件记录了数据库的状态。compaction在添加新文件和从数据库删除现有的文件后，会将这些操作记录到MANIFEST文件。事务日志是被批量提交到MANIFEST文件中的，目的是为了减少对MANIFEST文件的重复同步访问。

Compaction过滤器

一些应用程序可能需要在Compaction过程中处理某些key。例如,一个支持TTL的数据库可能删除过期的key，这可以通过定义一个Compaction过滤器完成。
如果应用程序想要不断删除旧数据,可以使用Compaction过滤掉丢弃过期的记录。RocksDB Compaction过滤器可以允许应用程序去修改对应key的value或作为Compaction过程的一部分直接丢弃key。

只读的模式

数据库可以在只读的模式下打开。只读模式下应用程序不能修改任何数据。这可以保证更高的读取性能,因为避免了代码执行路径的切换和锁的使用。

数据库调试日志

RocksDB的详细日志被写入到名为LOG*的文件中。这些日志用于调试和分析运行中的系统。可以按配置的指定周期记录日志。

数据压缩

RocksDB支持snappy,zlib,bzip2 lz4和lz4_hc压缩算法。对不同层的数据可以配置不同的压缩算法。一般来说,90%的数据保存在Lmax层。
一个典型的安装可能是L0-L2层不配置压缩算法,中间层用snappy压缩算法，而Lmax层采用zlib压缩。

事务日志

RocksDB将事务日志保存在logfile文件中以防止系统崩溃。系统启动时会重新处理日志文件。logfile和_sstfile_s可以存放在不同目录下，比如下面的场景，
当你希望将所有数据文件存储在非持久但快速的存储设备中，同时把事务日志保存在存取速度慢但持久的存储设备中。

来源：oschina

链接：https://my.oschina.net/u/4393724/blog/3237971

标签

聊聊storm trident的state

↘锁芯ラ — Sat, 30 Nov 2019 18:11:09 +0000

聊聊storm trident的state ↘锁芯ラ 2019-12-01 02:11:09

序

本文主要研究一下storm trident的state

StateType

storm-2.0.0/storm-client/src/jvm/org/apache/storm/trident/state/StateType.java

public enum StateType {
    NON_TRANSACTIONAL,
    TRANSACTIONAL,
    OPAQUE
}

StateType有三种类型，NON_TRANSACTIONAL非事务性，TRANSACTIONAL事务性，OPAQUE不透明事务
对应的spout也有三类，non-transactional、transactional以及opaque transactional

State

storm-2.0.0/storm-client/src/jvm/org/apache/storm/trident/state/State.java

/**
 * There's 3 different kinds of state:
 *
 * 1. non-transactional: ignores commits, updates are permanent. no rollback. a cassandra incrementing state would be like this 2.
 * repeat-transactional: idempotent as long as all batches for a txid are identical 3. opaque-transactional: the most general kind of state.
 * updates are always done based on the previous version of the value if the current commit = latest stored commit Idempotent even if the
 * batch for a txid can change.
 *
 * repeat transactional is idempotent for transactional spouts opaque transactional is idempotent for opaque or transactional spouts
 *
 * Trident should log warnings when state is idempotent but updates will not be idempotent because of spout
 */
// retrieving is encapsulated in Retrieval interface
public interface State {
    void beginCommit(Long txid); // can be null for things like partitionPersist occuring off a DRPC stream

    void commit(Long txid);
}

non-transactional，忽略commits，updates是持久的，没有rollback，cassandra的incrementing state属于这个类型；at-most或者at-least once语义
repeat-transactional，简称transactional，要求不管是否replayed，同一个batch的txid始终相同，而且里头的tuple也不变，一个tuple只属于一个batch，各个batch之间不会重叠；对于state更新来说，replay遇到相同的txid，即可跳过；在数据库需要较少的state，但是容错性较差，保证exactly once语义
opaque-transactional，简称opaque，是用的比较多的一类，它的容错性比transactional强，它不要求一个tuple始终在同一个batch/txid，也就是说允许一个tuple在这个batch处理失败，但是在其他batch中处理成功，但是它可以保证每个tuple只在某一个batch中exactly成功处理一次；OpaqueTridentKafkaSpout就是这个类型的实现，它能容忍kafka节点丢失的错误；对于state更新来说，replay遇到相同的txid，则需要基于prevValue使用当前的值覆盖掉；在数据库需要更多空间来存储state，但是容错性好，保证exactly once语义

MapState

storm-2.0.0/storm-client/src/jvm/org/apache/storm/trident/state/map/MapState.java

public interface MapState<T> extends ReadOnlyMapState<T> {
    List<T> multiUpdate(List<List<Object>> keys, List<ValueUpdater> updaters);

    void multiPut(List<List<Object>> keys, List<T> vals);
}

MapState继承了ReadOnlyMapState接口，而ReadOnlyMapState则继承了State接口
这里主要举MapState的几个实现类分析一下

NonTransactionalMap

storm-2.0.0/storm-client/src/jvm/org/apache/storm/trident/state/map/NonTransactionalMap.java

public class NonTransactionalMap<T> implements MapState<T> {
    IBackingMap<T> _backing;

    protected NonTransactionalMap(IBackingMap<T> backing) {
        _backing = backing;
    }

    public static <T> MapState<T> build(IBackingMap<T> backing) {
        return new NonTransactionalMap<T>(backing);
    }

    @Override
    public List<T> multiGet(List<List<Object>> keys) {
        return _backing.multiGet(keys);
    }

    @Override
    public List<T> multiUpdate(List<List<Object>> keys, List<ValueUpdater> updaters) {
        List<T> curr = _backing.multiGet(keys);
        List<T> ret = new ArrayList<T>(curr.size());
        for (int i = 0; i < curr.size(); i++) {
            T currVal = curr.get(i);
            ValueUpdater<T> updater = updaters.get(i);
            ret.add(updater.update(currVal));
        }
        _backing.multiPut(keys, ret);
        return ret;
    }

    @Override
    public void multiPut(List<List<Object>> keys, List<T> vals) {
        _backing.multiPut(keys, vals);
    }

    @Override
    public void beginCommit(Long txid) {
    }

    @Override
    public void commit(Long txid) {
    }
}

NonTransactionalMap包装了IBackingMap，beginCommit及commit方法都不做任何操作
multiUpdate方法构造List<T> ret，然后使用IBackingMap的multiPut来实现

TransactionalMap

storm-2.0.0/storm-client/src/jvm/org/apache/storm/trident/state/map/TransactionalMap.java

public class TransactionalMap<T> implements MapState<T> {
    CachedBatchReadsMap<TransactionalValue> _backing;
    Long _currTx;

    protected TransactionalMap(IBackingMap<TransactionalValue> backing) {
        _backing = new CachedBatchReadsMap(backing);
    }

    public static <T> MapState<T> build(IBackingMap<TransactionalValue> backing) {
        return new TransactionalMap<T>(backing);
    }

    @Override
    public List<T> multiGet(List<List<Object>> keys) {
        List<CachedBatchReadsMap.RetVal<TransactionalValue>> vals = _backing.multiGet(keys);
        List<T> ret = new ArrayList<T>(vals.size());
        for (CachedBatchReadsMap.RetVal<TransactionalValue> retval : vals) {
            TransactionalValue v = retval.val;
            if (v != null) {
                ret.add((T) v.getVal());
            } else {
                ret.add(null);
            }
        }
        return ret;
    }

    @Override
    public List<T> multiUpdate(List<List<Object>> keys, List<ValueUpdater> updaters) {
        List<CachedBatchReadsMap.RetVal<TransactionalValue>> curr = _backing.multiGet(keys);
        List<TransactionalValue> newVals = new ArrayList<TransactionalValue>(curr.size());
        List<List<Object>> newKeys = new ArrayList();
        List<T> ret = new ArrayList<T>();
        for (int i = 0; i < curr.size(); i++) {
            CachedBatchReadsMap.RetVal<TransactionalValue> retval = curr.get(i);
            TransactionalValue<T> val = retval.val;
            ValueUpdater<T> updater = updaters.get(i);
            TransactionalValue<T> newVal;
            boolean changed = false;
            if (val == null) {
                newVal = new TransactionalValue<T>(_currTx, updater.update(null));
                changed = true;
            } else {
                if (_currTx != null && _currTx.equals(val.getTxid()) && !retval.cached) {
                    newVal = val;
                } else {
                    newVal = new TransactionalValue<T>(_currTx, updater.update(val.getVal()));
                    changed = true;
                }
            }
            ret.add(newVal.getVal());
            if (changed) {
                newVals.add(newVal);
                newKeys.add(keys.get(i));
            }
        }
        if (!newKeys.isEmpty()) {
            _backing.multiPut(newKeys, newVals);
        }
        return ret;
    }

    @Override
    public void multiPut(List<List<Object>> keys, List<T> vals) {
        List<TransactionalValue> newVals = new ArrayList<TransactionalValue>(vals.size());
        for (T val : vals) {
            newVals.add(new TransactionalValue<T>(_currTx, val));
        }
        _backing.multiPut(keys, newVals);
    }

    @Override
    public void beginCommit(Long txid) {
        _currTx = txid;
        _backing.reset();
    }

    @Override
    public void commit(Long txid) {
        _currTx = null;
        _backing.reset();
    }
}

TransactionalMap采取的是CachedBatchReadsMap<TransactionalValue>，这里泛型使用的是TransactionalValue，beginCommit会设置当前的txid，重置_backing，commit的时候会重置txid，然后重置_backing
multiUpdate方法中判断如果_currTx已经存在值，且该值!retval.cached(即不是本次事务中multiPut进去的)，那么不会更新该值(skip the update)，使用newVal = val
multiPut方法构造批量的TransactionalValue，然后使用CachedBatchReadsMap.multiPut(List<List<Object>> keys, List<T> vals)方法，该方法更新值之后会更新到缓存

OpaqueMap

storm-2.0.0/storm-client/src/jvm/org/apache/storm/trident/state/map/OpaqueMap.java

public class OpaqueMap<T> implements MapState<T> {
    CachedBatchReadsMap<OpaqueValue> _backing;
    Long _currTx;

    protected OpaqueMap(IBackingMap<OpaqueValue> backing) {
        _backing = new CachedBatchReadsMap(backing);
    }

    public static <T> MapState<T> build(IBackingMap<OpaqueValue> backing) {
        return new OpaqueMap<T>(backing);
    }

    @Override
    public List<T> multiGet(List<List<Object>> keys) {
        List<CachedBatchReadsMap.RetVal<OpaqueValue>> curr = _backing.multiGet(keys);
        List<T> ret = new ArrayList<T>(curr.size());
        for (CachedBatchReadsMap.RetVal<OpaqueValue> retval : curr) {
            OpaqueValue val = retval.val;
            if (val != null) {
                if (retval.cached) {
                    ret.add((T) val.getCurr());
                } else {
                    ret.add((T) val.get(_currTx));
                }
            } else {
                ret.add(null);
            }
        }
        return ret;
    }

    @Override
    public List<T> multiUpdate(List<List<Object>> keys, List<ValueUpdater> updaters) {
        List<CachedBatchReadsMap.RetVal<OpaqueValue>> curr = _backing.multiGet(keys);
        List<OpaqueValue> newVals = new ArrayList<OpaqueValue>(curr.size());
        List<T> ret = new ArrayList<T>();
        for (int i = 0; i < curr.size(); i++) {
            CachedBatchReadsMap.RetVal<OpaqueValue> retval = curr.get(i);
            OpaqueValue<T> val = retval.val;
            ValueUpdater<T> updater = updaters.get(i);
            T prev;
            if (val == null) {
                prev = null;
            } else {
                if (retval.cached) {
                    prev = val.getCurr();
                } else {
                    prev = val.get(_currTx);
                }
            }
            T newVal = updater.update(prev);
            ret.add(newVal);
            OpaqueValue<T> newOpaqueVal;
            if (val == null) {
                newOpaqueVal = new OpaqueValue<T>(_currTx, newVal);
            } else {
                newOpaqueVal = val.update(_currTx, newVal);
            }
            newVals.add(newOpaqueVal);
        }
        _backing.multiPut(keys, newVals);
        return ret;
    }

    @Override
    public void multiPut(List<List<Object>> keys, List<T> vals) {
        List<ValueUpdater> updaters = new ArrayList<ValueUpdater>(vals.size());
        for (T val : vals) {
            updaters.add(new ReplaceUpdater<T>(val));
        }
        multiUpdate(keys, updaters);
    }

    @Override
    public void beginCommit(Long txid) {
        _currTx = txid;
        _backing.reset();
    }

    @Override
    public void commit(Long txid) {
        _currTx = null;
        _backing.reset();
    }

    static class ReplaceUpdater<T> implements ValueUpdater<T> {
        T _t;

        public ReplaceUpdater(T t) {
            _t = t;
        }

        @Override
        public T update(Object stored) {
            return _t;
        }
    }
}

OpaqueMap采取的是CachedBatchReadsMap<OpaqueValue>，这里泛型使用的是OpaqueValue，beginCommit会设置当前的txid，重置_backing，commit的时候会重置txid，然后重置_backing
与TransactionalMap的不同，这里在multiPut的时候，使用的是ReplaceUpdater，然后调用multiUpdate强制覆盖
multiUpdate方法与TransactionalMap的不同，它是基于prev值来进行update的，算出newVal

小结

trident严格按batch的顺序更新state，比如txid为3的batch必须在txid为2的batch处理完之后才能处理
state分三种类型，分别是non-transactional、transactional、opaque transactional，对应的spout也是这三种类型
- non-transactional无法保证exactly once，它可能是at-least once或者at-most once；其state计算参考NonTransactionalMap，对于beginCommit及commit操作都无处理
- transactional类型能够保证exactly once，但是要求比较严格，要同一个batch的txid及tuple在replayed的时候仍然保持一致，因此容错性差一点，但是它的state计算相对简单，参考TransactionalMap，遇到同一个txid的值，skip掉即可
- opaque transactional类型也能够保证exactly once，它允许一个tuple处理失败之后，出现在其他batch中处理，因而容错性好，但是state计算要多存储prev值，参考OpaqueMap，遇到同一个txid的值，使用prev值跟当前值进行覆盖
trident将保证exactly once的state的计算都封装好了，使用的时候，在persistentAggregate传入相应的StateFactory即可，支持多种StateType的factory可以选择使用StateType属性，通过传入不同的参数构造不同transactional的state；也可以通过实现StateFactory自定义实现state factory，另外也可以通过继承BaseQueryFunction来自定义stateQuery查询，自定义更新的话，可以继承BaseStateUpdater，然后通过partitionPersist传入

doc

来源：oschina

链接：https://my.oschina.net/u/2922256/blog/2436027

标签

MultiGet

ES系列四、ES6.3常用api之文档类api

1.Index API: 创建并建立索引

2.Get API: 获取文档

3.DELETE API: 删除文档

4.UPDATE API: 更新文档

5.Multi Get API: 一次批量获取文档

6.Bulk API: 批量操作，增删改查

1.本地文件批量操作

2.resp 方法

7.DELETE By Query API: 查询删除

7.1.删除所有

7.2.支持路由查询（routing=XXX,匹配分片数）

8.update更新api

8.1.脚本更新

8.2.新增字段

8.3.删除字段

8.4.存在就更新

8.5.更新部分字段

8.6.upsert：存在就更新，不存在插入

9.UPDATE BY QUERY API:查询更新

9.1.更新，重新索引

9.2.查询更新

9.3.查询脚本更新

9.4.使用TASK API获取所有正在运行的逐个查询请求的状态

10.Reindex API：重新索引

10.1.复制整个索引

10.2.复制匹配的文档

10.3.复制多个索引文档

10.4.是否覆盖版本号

10.5.只复制不存在的记录，已经存在的记录提示冲突

10.6.排序复制指定数量

10.7.复制部分字段

10.8.过滤修改元数据再复制

10.9.从远程复制

10.10.查看重建索引任务

11.term Vectors:分词api

11.1. term的基本信息

11.2 term的统计信息

11.3字段的统计信息

11.5采集term信息的方式

11.6 index-time方式

11.7 query-time方式

11.8 手动指定analyzer来生成termvector

11.9 在线文档及时生成termvector

11.10 term的统计信息

11.11 term过滤参数说明

12 批量返回分词：Multi termvectors API

12.1 index-time

12.2及时批量生成

12.2.返回该索引全部文档的分词统计

13.?refresh

13.1.refresh=true

13.2.refresh=wait_for

13.3.refresh=false

RedisTemplate常用集合使用说明-opsForHash(四)

1、put(H key, HK hashKey, HV value)

2、values(H key)

3、entries(H key)

4、get(H key, Object hashKey)

5、hasKey(H key, Object hashKey)

6、keys(H key)

7、size(H key)

8、increment(H key, HK hashKey, double delta)

9、increment(H key, HK hashKey, long delta)

10、multiGet(H key, Collection<HK> hashKeys)

11、putAll(H key, Map<? extends HK,? extends HV> m)

12、putIfAbsent(H key, HK hashKey, HV value)

13、scan(H key, ScanOptions options)

14、delete(H key, Object... hashKeys)

（补充）注意：Map集合中put与putIfAbsent的区别

OpenUOM移动性改造-靠新的session iD而不是IP/Port识别客户端

设备移动性的挑战

会话层真的太重要了

OpenUOM的故事

解决问题的步骤

关于本文的引申

redis 大key 问题

处理方法：

分拆

`13.1.refresh=true`

`13.2.refresh=wait_for`

`13.3.refresh=false`

1、put`(H key,` `HK hashKey,` `HV value)`

5、hasKey`(H key,` `Object hashKey)`

10、multiGet`(H key,` `Collection<HK> hashKeys)`