在今天的文章中，我将着重介绍 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_alive=5m。
POST /twitter/_pit?keep_alive=2m上面的命令将返回如下的结果：
{
"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_alive=2m运行完后，我们得到一个不一样的 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