湖南网站建设欧黎明,东莞网站排名优化,昆明网站建设高端定制,wordpress 零售电商Elasticsearch#xff1a;时间点 API-CSDN博客
在今天的文章中#xff0c;我将着重介绍 Point in time API。在接下来的文章中#xff0c;我将介绍如何运用 PIT 来对搜索结果进行分页。这也是被推荐使用的方法。
Point in time API 默认情况下#xff0c;搜索请求针对目标…Elasticsearch时间点 API-CSDN博客
在今天的文章中我将着重介绍 Point in time API。在接下来的文章中我将介绍如何运用 PIT 来对搜索结果进行分页。这也是被推荐使用的方法。
Point in time API 默认情况下搜索请求针对目标索引的最新可见数据执行这称为时间点。 Elasticsearch pit时间点是一个轻量级的视图可以查看数据在启动时的状态。 在某些情况下最好使用同一时间点执行多个搜索请求。 例如如果在 search_after 请求之间发生刷新则这些请求的结果可能不一致因为搜索之间发生的更改仅在最近的时间点可见。
先决条件 如果启用了 Elasticsearch 安全特性你必须具有目标数据流、索引或别名的读取索引权限。要在某个时间点 (PIT) 中搜索别名你必须具有该别名的数据流或索引的读取索引权限。 下面我们将以一些例子来展示如何使用 PIT 来进行搜索。我们首先来导入我们的索引
POST _bulk { index : { _index : twitter, _id: 1} } {user:双榆树-张三,message:今儿天气不错啊出去转转去,uid:2,age:20,city:北京,province:北京,country:中国,address:中国北京市海淀区,location:{lat:39.970718,lon:116.325747}} { index : { _index : twitter, _id: 2 }} {user:东城区-老刘,message:出发下一站云南,uid:3,age:30,city:北京,province:北京,country:中国,address:中国北京市东城区台基厂三条3号,location:{lat:39.904313,lon:116.412754}} { index : { _index : twitter, _id: 3} } {user:东城区-李四,message:happy birthday!,uid:4,age:30,city:北京,province:北京,country:中国,address:中国北京市东城区,location:{lat:39.893801,lon:116.408986}} { index : { _index : twitter, _id: 4} } {user:朝阳区-老贾,message:123,gogogo,uid:5,age:35,city:北京,province:北京,country:中国,address:中国北京市朝阳区建国门,location:{lat:39.718256,lon:116.367910}} { index : { _index : twitter, _id: 5} } {user:朝阳区-老王,message:Happy BirthDay My Friend!,uid:6,age:50,city:北京,province:北京,country:中国,address:中国北京市朝阳区国贸,location:{lat:39.918256,lon:116.467910}} { index : { _index : twitter, _id: 6} } {user:虹桥-老吴,message:好友来了都今天我生日好友来了,什么 birthday happy 就成!,uid:7,age:90,city:上海,province:上海,country:中国,address:中国上海市闵行区,location:{lat:31.175927,lon:121.383328}} 我们使用上面的 bulk 命令导入6个数据。它将创建一个叫做 twitter 的索引。
在搜索请求中使用之前必须明确打开时间点。 keep_alive 参数告诉 Elasticsearch 它应该保持一个时间点存活多久例如 ?keep_alive5m。
POST /twitter/_pit?keep_alive2m 上面的命令将返回如下的结果
{ id : g-azAwEHdHdpdHRlchZIck44aVdSNlFMNnEyTmVMUGJEVm9RABZxNnpoTVIxQVFIeTRkci1MSGlibU9BAAAAAAAAARtiFldSS2x2LVZJUU5xajU1ZkxCN2dyMUEAARZIck44aVdSNlFMNnEyTmVMUGJEVm9RAAA } 接下来我们可以使用如下的命令来对我们的索引进行搜索
GET _search { query: { match: { city: 北京 } }, pit: { id : g-azAwEHdHdpdHRlchZIck44aVdSNlFMNnEyTmVMUGJEVm9RABZxNnpoTVIxQVFIeTRkci1MSGlibU9BAAAAAAAAARtiFldSS2x2LVZJUU5xajU1ZkxCN2dyMUEAARZIck44aVdSNlFMNnEyTmVMUGJEVm9RAAA, keep_alive: 2m } } 在使用上面的搜索时必须注意的一点是我们不能使用如下的格式
GET /twitter/_search 也就是说我们不能使用索引名作为请求的一部分。我们必须注意一下的几个方面
带有 pit 参数的搜索请求不得指定 index、routing 和 preference因为这些参数是从时间点复制的。 id 参数告诉 Elasticsearch 从这个时间点使用上下文执行请求。 keep_alive 参数告诉 Elasticsearch 应该将时间点的生存时间延长多长时间。 在上面我们设置 keep_alive 为2分钟。当我们在2分钟后再执行上面的搜索时我们可以看到如下的错误信息
{ error : { root_cause : [ { type : search_context_missing_exception, reason : No search context found for id [72546] } ], type : search_phase_execution_exception, reason : all shards failed, phase : query, grouped : true, failed_shards : [ { shard : 0, index : twitter, node : q6zhMR1AQHy4dr-LHibmOA, reason : { type : search_context_missing_exception, reason : No search context found for id [72546] } } ] }, status : 404 } 重要开放时间点请求和后续的每个搜索请求可以返回不同的 id 因此对于下一个搜索请求总是使用最近收到的 id。
我们接下来做另外一个实验。我们首先再次运行如下的命令
POST /twitter/_pit?keep_alive2m 运行完后我们得到一个不一样的 id尽管这个新的 id 和上次返回的值长的非常像。
我们使用最新的 id 来做如下的查询
GET _search { query: { match: { city: 北京 } }, pit: { id : g-azAwEHdHdpdHRlchZIck44aVdSNlFMNnEyTmVMUGJEVm9RABZxNnpoTVIxQVFIeTRkci1MSGlibU9BAAAAAAAAAR8tFldSS2x2LVZJUU5xajU1ZkxCN2dyMUEAARZIck44aVdSNlFMNnEyTmVMUGJEVm9RAAA, keep_alive: 2m } } 我们可以看到有5个这样的文档 我们接下来使用如下的命令来添加一个新的文档
PUT twitter/_doc/7 { user: 张三, message: 今天天气真好, uid: 8, age: 35, city: 北京, province: 北京, country: 中国, address: 中国北京市朝阳区, location: { lat: 31.175927, lon: 121.383328 } }
请注意这个文档的 city 字段也是 “北京”那么在新增加一个文档后再次来做如下的查询
GET _search { query: { match: { city: 北京 } }, pit: { id : g-azAwEHdHdpdHRlchZIck44aVdSNlFMNnEyTmVMUGJEVm9RABZxNnpoTVIxQVFIeTRkci1MSGlibU9BAAAAAAAAAR8tFldSS2x2LVZJUU5xajU1ZkxCN2dyMUEAARZIck44aVdSNlFMNnEyTmVMUGJEVm9RAAA, keep_alive: 2m } } 我们可以看到和之前一模一样的结果还是5个文档。
然后当我们做如下的查询
GET /twitter/_search { query: { match: { city: 北京 } } } 我们可以清楚地看到有6个文档的 city 是 “北京”
这到底是怎么回事呢究其原因就是当我们查询时使用 pit 参数时它只能查询在那个时间点之前的所有文档而后面新增加的文档不能被查询到。这个在实际的很多应用中非常有用。比如针对一个快速变化的索引来说我们想对它进行表格化我们不希望在我们进行分页时每次得到的数据集是不同的。
保持时间点活着 传递给开放时间点请求和搜索请求的 keep_alive 参数延长了相应时间点的生存时间。 该值例如 1m参见时间单位不需要足够长来处理所有数据 — 它只需要足够长以用于下一个请求。
通常后台合并过程通过将较小的段合并在一起以创建新的更大的段来优化索引。 一旦不再需要较小的段它们就会被删除。 但是开放时间点会阻止删除旧段因为它们仍在使用中。
提示保持旧段segment处于活动状态意味着需要更多的磁盘空间和文件句柄。 确保你已将节点配置为具有充足的空闲文件句柄。 请参阅文件描述符。
此外如果一个段segment包含已删除或更新的文档那么该时间点必须跟踪该段中的每个文档在初始搜索请求时是否处于活动状态。 如果索引上有许多打开的时间点并且会受到持续删除或更新的影响请确保你的节点有足够的堆空间。
你可以使用节点统计 API 检查有多少时间点即搜索上下文打开
GET /_nodes/stats/indices/search 关闭时间点 API 时间点在其 keep_alive 结束后自动关闭。 然而保持时间点是有代价的如上一节所述。 一旦不再用于搜索请求就应关闭时间点。我们可以通过如下的命令来对它进行关闭
DELETE /_pit { id : g-azAwEHdHdpdHRlchZIck44aVdSNlFMNnEyTmVMUGJEVm9RABZxNnpoTVIxQVFIeTRkci1MSGlibU9BAAAAAAAAASLCFldSS2x2LVZJUU5xajU1ZkxCN2dyMUEAARZIck44aVdSNlFMNnEyTmVMUGJEVm9RAAA } 如果该 id 还是 alive 的状态那么它将返回
{ succeeded : true, num_freed : 1 } 在上面如果返回 true则与时间点 ID 关联的所有搜索上下文都将成功关闭。num_freed 表示多少个搜索上下文数量已成功关闭。
参考
【1】https://www.elastic.co/guide/en/elasticsearch/reference/current/point-in-time-api.html ———————————————— 版权声明本文为CSDN博主「Elastic 中国社区官方博客」的原创文章遵循CC 4.0 BY-SA版权协议转载请附上原文出处链接及本声明。 原文链接https://blog.csdn.net/UbuntuTouch/article/details/119926953
