Elasticsearch系列(9)Search之分页、排序

1. 分页

1.1 普通分页

默认情况下,search API返回前10个匹配的文档。

如果需要每页返回一个更大的结果集,可以使用search API的size和from参数。size参数表示要返回的匹配文档的数量。from参数是表示从完整结果集起点的偏移量,表示忽略前面多少个文档开始返回。

例如,请求size参数设置为2,from偏移量设置为1,表示跳过第1个文档,请求返回2个匹配文档。请求示例如下:

PUT /my_index_01
{
  "mappings": {
    "properties": {
       "content": {
        "type": "text"
      },
      "@timestamp":{
        "type": "long",
        "doc_values": true
      }
    }
  }
}
POST /my_index_01/_create/1
{"content":"Quick Brown Fox", "@timestamp": 1283930213}
POST /my_index_01/_create/2
{"content":"Quick White Fox", "@timestamp": 1283930813}
POST /my_index_01/_create/3
{"content":"Quick Gray Fox", "@timestamp": 1283931213}
GET my_index_01/_search
{"from":1,"size":2,"query":{"match":{"content":"Fox"}}}
  • size由索引配置参数index.max_result_window限制,默认情况下,size不能大于10,000。
  • 深度分页或一次请求多个结果会导致搜索速度变慢。结果在返回之前需进行排序,由于搜索请求通常跨越多个分片,首先每个分片必须生成自己的排序结果,然后将这些单独的结果合并起来进行排序,以确保总体排序是正确的。如果有深度分页的需要,官方建议使用滚动搜索(scroll search)作为替代方案。

1.2 滚动搜索结果

滚动搜索API(scroll API)可以用于单个搜索请求大量结果,甚至所有结果,其使用方式与数据库上使用游标相似。

滚动(scroll)的目的不是用于实时用户请求,而是用于处理大量数据,例如,将一个数据流或索引的内容重新索引到具有不同配置的新数据流或索引中。为了使用滚动(scroll),初始搜索请求应该在查询字符串中指定scroll参数,scroll参数告诉Elasticsearch应该保持“搜索上下文”活跃多久。滚动搜索操作示例如下:

POST my_index_01/_search?scroll=1m
{
  "size": 100,
  "query": {
    "match": {
      "content": "Fox"
    }
  }
}

返回结果片段:

"_scroll_id" : "DXF1ZXJ5QW5kRmV0Y2gBAAAAAAAAA_oWaG9ielJ2bV9UM3VOb0pDVUN1R3ViZw==",
  • 上面的搜索请求结果中包含一个_scroll_id,它应该被传递给滚动API(scroll API),以便检索下一批结果。示例如下:
POST /_search/scroll //1
{
  "scroll": "1m", //2
  "scroll_id": "DXF1ZXJ5QW5kRmV0Y2gBAAAAAAAABXsWaG9ielJ2bV9UM3VOb0pDVUN1R3ViZw==" //3
}

注释1:URL不需要包含索引名字
注释2:scroll参数告诉Elasticsearch应该保持“搜索上下文”再打开1m。
注释3:与上一次搜索请求返回结果中的_scroll_id值保持一致。

滚动搜索上下文

滚动(scroll)返回在初始搜索请求时匹配搜索的所有文档。它忽略对这些文档的任何后续更改。scroll_id标识一个搜索上下文,它跟踪Elasticsearch返回正确文档所需的所有内容。搜索上下文在初始请求时创建,并由后续请求保持活动状态。

scroll参数(传递给搜索请求和每个滚动请求)告诉Elasticsearch它应该保持搜索上下文存活多长时间。它的值(例如1m,表示1分钟)不需要足够长来处理所有数据——它只需要足够长来处理前一批结果。每个滚动请求(带scroll参数)设置一个新的到期时间。如果滚动请求没有传递scroll参数,那么搜索上下文将作为滚动请求的一部分被释放。

通常,后台合并过程通过合并较小的段来优化索引,从而创建新的、更大的段。一旦不再需要较小的段,就会删除它们。这个过程在滚动期间也会进行,但是一个打开的搜索上下文会防止旧的片段被删除,因为它们仍在使用中。保持较旧的段活跃意味着需要更多的磁盘空间和文件句柄。需要确保已将节点配置为具有足够的空闲文件句柄。

此外,如果一个段包含已删除或更新的文档,那么搜索上下文必须跟踪段中的每个文档在初始搜索请求时是否处于活动状态。如果一个索引上有许多打开的滚动(scroll),而该索引正在被删除或更新,那么需要确保节点有足够的堆空间。

为了防止由于打开了太多的滚动(scroll)而引起的问题,一般不允许打开超过一定限制的滚动。默认情况下,打开的最大scroll数是500。这个限制可以通过集群设置search.max_open_scroll_context更新。

删除滚动

当scroll时间已过期时,搜索上下文将自动删除。也可使用clear-scroll API明确地删除滚动(scroll),操作示例如下:

DELETE /_search/scroll
{
  "scroll_id" : "DXF1ZXJ5QW5kRmV0Y2gBAAAAAAAABfkWaG9ielJ2bV9UM3VOb0pDVUN1R3ViZw=="
}
  • 支持多个scroll_id数组集删除。

通过_all参数删除所有搜索上下文:

DELETE /_search/scroll/_all

切分滚动

对于滚动查询会返回大量的文档,这些文档可能切分滚动在多个切片上,并且每个切片可独立消费:

POST my_index_01/_search?scroll=1m
{
  "slice": {
    "id": 0,
    "max": 2
  },
  "size": 1,
  "query": {
    "match": {
      "content": "Fox"
    }
  }
}
GET my_index_01/_search?scroll=1m
{
  "slice": {
    "id": 1,
    "max": 2
  },
  "query": {
    "match": {
      "content": "Fox"
    }
  }
}
  • slice.id表示切片的id,slice.max表示切片的最大数量。
  • 第一个请求的结果返回属于第一个切片的文档(id: 0),而第二个请求的结果返回属于第二个切片的文档。由于切片的最大数量被设置为2,所以两个请求结果的并集相当于不进行切片的滚动查询(scroll query)的结果。
  • 默认情况下,切分首先在分片(shard)上进行,然后使用文档_id值按照哈希取模公式进行切分。公式如下:
    slice(doc) = floorMod(hashCode(doc._id), max)
    例如,如果分片(shard)的数量等于2,用户要求4个切片,那么切片0和2分配给第一个分片(shard),切片1和3是分配给第二个分片(shard)。
  • 每个切片滚动(scroll)都是独立的,可以像任何滚动(scroll)请求一样并行处理。

如果切片的数量大于分片(shard)的数量,切片过滤器在第一次调用时非常慢,它的复杂度为O(N),内存消耗等于每切片N位,其中N是分片(shard)中的文档总数。在几个调用之后,Elasticsearch会缓存过滤器,随后的调用速度会加快,但是应该限制并行执行的切片查询的数量,以避免内存爆炸。为了完全避免这种开销,可以使用另一个字段的doc_values来切分,但用户必须确保该字段具有以下属性:
(1)字段是数字的。
(2)doc_values在该字段上启用
(3)每个文档都应该包含一个值。如果文档中指定的字段有多个值,则使用第一个值。
(4)每个文档的值应该在创建文档且不更新时设置一次。这确保了每个片都得到确定性的结果。
(5)字段应该有高基数。这确保了每个切片获得大致相同数量的文档。
操作示例如下:

POST my_index_01/_search?scroll=1m
{
  "slice": {
    "field": "@timestamp",
    "id": 0,
    "max": 2
  },
  "size": 1,
  "query": {
    "match": {
      "content": "Fox"
    }
  }
}

注:默认情况下,每次滚动(scroll)允许的最大切片数限制为1024。可以通过索引设置项index.max_slices_per_scroll来更新限制数。

1.3 search after

search_after参数结合上一次返回结果集中最后一个文档的排序值(sort values)来检索下一页的数据结果:

GET my_index_01/_search
{
  "size": 2,
  "query": {
    "match": {
      "content": "Fox"
    }
  },
  "search_after": [1283930813], //1
  "sort": [
    {"@timestamp": "asc"}
  ]
}

注释1:支持多个排序值的数组,上次查询的最后一个文档的@timestamp字段值是1283930813。即查询@timestamp值大于1283930813的数据

  • 当search_after参数使用时,from参数必须设置0或-1。

2. 排序

2.1 排序介绍

排序按字段级别定义,允许按照一个或多个字段排序,排序字段可以升序asc或降序desc。
假设索引映射如下:

PUT /my_index_01
{
  "mappings": {
    "properties": {
      "content": {
        "type": "text"
      },
      "post_date": {
        "type": "date"
      },
      "user": {
        "type": "keyword"
      },
      "name": {
        "type": "keyword"
      },
      "age": {
        "type": "integer"
      }
    }
  }
}

其搜索结果按照字段post_date升序、字段user.name降序、字段age降序、文档得分_score升序,多字段排序示例如下:

GET /my_index_01/_search
{
  "sort" : [
    { "post_date" : {"order" : "asc"}},
    "user", { "name" : "desc" },
    { "age" : "desc" },
    "_score"
  ],
  "query" : {
    "term" : { "user" : "johnny" }
  }
}

2.2 排序模式选项

Elasticsearch支持按数组或多值字段排序。模式选项(mode option)控制选择什么数组值来对它所属的文档进行排序。排序模式选项可以有以下值:

mode值 说明
min 选择最小值
max 选择最大值
sum 使用所有值的和作为排序值。
仅适用于基于数字的数组字段
avg 使用所有值的平均值作为排序值。
仅适用于基于数字的数组字段。
median 使用所有值的中值作为排序值。
仅适用于基于数字的数组字段。

升序排序的默认排序模式是min—选择最小值。降序排列的默认排序模式是max—选择最大值。

例如,字段price有多个价格,计算出每个文档平均价格按照升序排序,操作示例如下:

PUT /my_index_01/_doc/1?refresh
{"product":"chocolate","price":[20,4]}
POST my_index_01/_search
{
  "query": {
    "term": {  "product": "chocolate" }
  },
  "sort": [
    { "price": { "order": "asc", "mode": "avg" } }
  ]
}

2.3 排序数值类型

对于数值字段,可以使用numeric_type参数可以将值从一种类型转换为另一种类型来进行排序。支持转换的类型有:["double", "long", "date", "date_nanos"]
例如,两个索引index_double和index_long,有相同字段名price,但是字段类型不同,使用numeric_type参数来进行排序示例如下:

PUT /index_double
{
  "mappings": {
    "properties": {
      "price": { "type": "double" }
    }
  }
}
PUT /index_long
{
  "mappings": {
    "properties": {
      "price": { "type": "long" }
    }
  }
}
POST /index_long,index_double/_search
{
   "sort" : [
      { "price" : { "numeric_type" : "double" }}
   ]
}
  • 上面的示例,index_long索引中price字段值被转换为double,以便与index_double索引生成的值兼容。

2.4 排序缺失值

缺失(missing)参数指定了如何处理缺少排序字段的文档,missing参数值可以设置为_last、_first或自定义值(用于缺失文档的排序值)。默认值是_last。

  • _last:表示排序在最后, 缺失字段值的文档排在最后面。
  • _first:表示排序在最前,缺失字段值的文档排在最前面。

操作示例如下:

PUT /my_index_01/_doc/1?refresh
{"product":"chocolate","price":[20,4]}
PUT /my_index_01/_doc/2?refresh
{"product":"chocolate"}
GET my_index_01/_search
{
  "sort" : [
    { "price" : {"missing" : "_last"} }
  ],
  "query" : {
    "term" : { "product" : "chocolate" }
  }
}

2.5 忽略未映射字段

默认情况下,如果没有与某个字段关联的映射,搜索请求将失败。通过unmapped_type选项允许忽略没有映射的字段,也不按照这些字段排序,避免了搜索请求时抛出异常。unmapped_type参数的值用于确定要生成的排序值,使用示例如下:

GET my_index_01/_search
{
  "sort" : [
    { "price" : {"unmapped_type" : "long"} }
  ],
  "query" : {
    "term" : { "product" : "chocolate" }
  }
}

上面的例子表示,如果索引映射中没有字段price,Elasticsearch指定一个类型是long的字段price,但是索引中所有文档都没有该字段的值。

2.6 地理空间数据排序

地理空间数据通过参数_geo_distance来排序,操作示例如下:

GET my_index_01/_search
{
  "sort" : [
    {
      "_geo_distance" : {
          "pin.location" : [-70, 40],
          "order" : "asc",
          "unit" : "km",
          "mode" : "min",
          "distance_type" : "arc",
          "ignore_unmapped": true
      }
    }
  ],
  "query" : {
    "term" : { "shop" : "华为官方舰旗店" }
  }
}

上面例子,文档的最终距离是将文档中字段pin.location包含的所有点到排序请求中给定pin.location字段的所有点的最小(mode模式定义)距离,参数说明如下:

  • distance_type:如何计算距离。可以是arc(默认),也可以是plane(速度更快,但在距离较远和接近极点时不准确)。
  • mode:如果一个字段有几个地理点怎么办? 默认情况下,升序排序时考虑最短的距离,降序排序时考虑最长的距离。支持的值是min,max,medianavg
  • unit:计算排序值时使用的单元。默认值是m(米)。
  • ignore_unmapped:指示是否应将未映射的字段视为丢失的值。将其设置为true相当于在字段排序中指定unmapped_type。默认值为false(未映射字段导致搜索失败)。
  • pin.location:排序计算距离的字段,坐标点数组。

2.7 基于脚本排序

可以基于自定义脚本排序,操作示例如下图所示:

基于自定义脚本排序

2.8 跟踪分数

当对某个字段进行排序时,不会计算文档分数,通过将track_scores设置为true来计算和跟踪分数。操作示例如下图所示:


跟踪分数

2.9 内存注意事项

当排序时,相关的已排序字段值被加载到内存中。这意味着每个分片(shard)应该需要足够的内存来存储这些数据。对于基于字符串的类型,排序的字段不应该被分析/标记。对于数值类型,如果可能,建议显式地将类型设置为更窄的类型(如short、integer和float)。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 217,734评论 6 505
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 92,931评论 3 394
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 164,133评论 0 354
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 58,532评论 1 293
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 67,585评论 6 392
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 51,462评论 1 302
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 40,262评论 3 418
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 39,153评论 0 276
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,587评论 1 314
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,792评论 3 336
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,919评论 1 348
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,635评论 5 345
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 41,237评论 3 329
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,855评论 0 22
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,983评论 1 269
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 48,048评论 3 370
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,864评论 2 354