Elasticsearch 的接口拾遗（十四）

川长思鸟来 2022-12-13 14:13 17阅读 0赞

这篇分析Elasticsearch 的部分接口：

**一、容量控制**

**1、\_split**  **接口**

\_split  接口可以在新索引中将每个主分片分裂为两个或更多分片，所以使用 split 扩容时分片总量都是成倍增加而不能逐个增加。使用  split  接口分裂分片虽 然会创建新的索引，但新索引中的数据只是通过文件系统硬连接到新索引中，所 以并不存在数据复制过程。而扩容的分片又是在本地分裂，所以不存在不同节点 间网络传输数据的开销，所以 split  扩容效率相对其他方案来说还是比较高的。 \_split 接口做动态打容需要预先设置索引的  number\_of\_routing\_shards  参数， Elasticsearch 向分片散列文档采用一致性哈希算法，这个参数实际上设置了索引 分片散列空间。所以分裂后分片数量必须是 number\_of\_routing\_shards  的因数，

同时是  number\_of\_shards  的倍数。

例如，设置  number\_of\_routing\_shards  为  12, number\_of\_shards  为  2 ，则分 片再分裂存在 2->4->12 、 2->6->12  和  2->12  三种可能的扩容路径。分裂后分片数 量可通过 \_ split  接口的  index. number\_of\_shards  参数设置，数量必须满足前述整 数倍的要求。上面讲解的这些规则比较抽象，下面通过创建一个具体示例来看一 下如何通过 split  接口扩容索引。 首先创建一个索引 employee, 将它的主分片数量  number\_ \_of \_shards  设置 为 2, 散列空间  number. of. routing shards  设置为  12 。然后，通过将索引的  blocks. write 参数设置为  true, 将索引设置为只读，这是因为使用  split  接口要求索引必须 为只读。最后调用 spit  接口将  enployee  索引的分片分裂到新索引 splited\_employee 中， index.number\_of\_shards  参数设置为  4 ，即分裂为  4  个分 片。如示例所示:

DELETE employee

PUT employee

"settings": \{

"number\_of\_shards":2,

"number\_of\_routing\_ shards":12

PUT /employee/\_settings

"blocks.write": true

PUT /employee/\_split/splited\_employee

"settings": \{

"index.number\_of\_shards":4,

"index.number\_of\_replicas":1,

"index.blocks.write":false

\},

"aliases": \{

"stu":\{\}

在执行成功后，可调用“ GET \_cat/shards"  查看分片。在返回结果中可以看 到 employee  索引共有  4  个分片，即  2  个主分片和  2  个副本分片 ; 新索引 splited\_employee 会有  8  个分片，即  4  个主分片和  4  个副本分片。 split  接口在创 建新索引的同时，会将原索引的配置也一同设置到新索引中。所以 index. blocks. write 参数也会一同被复制过来，但这可能并不是我们想要的。 所以在分裂分片的同时支持通过  aliases  和  settings  设置新索引的别名和配置， 所以可以在分裂分片的同时将 index. blocks. write  参数覆盖。在示例中就将这个 参数覆盖了，同时还添加了新的别名 stu 。另外，还可以在地址中添加  copy\_ settings = false 参数禁止从源索引中复制配置，但这个参数在版本  8  中有可能被 废止，所以添加这个参数会收到警告。 使用 split  接口成功分裂分片后，原索引并不会被自动删除。通过原索引和 新索引都可以查看到相同的文档数据，原索引是否删除应根据业务需要具体判断。

**2、\_shrink**  **接口**

与 \_split  接口相反， \_shrink  接口用于缩减索引分片。尽管它们在逻辑上正好 相反，但它们在应用时的规则基本上是一致的。比如，shrink  接口在缩减索引分 片数量时也要求原始分片数量必须是缩减后分片数量的整数倍。例如原始分片数 量为 12 ，则可以按  12->6->3->1  的路径缩减，也可以按  12->4->2->1  的路径缩减。 在调用\_shrink  接口前要满足两个条件，第一个条件与 \_split  接口类似，就是要求 索引在缩容期间必须只读; 第二个条件有些特殊，就是要求索引所有分片 ( 包括副 本分片) 都要复制一份存储在同一节点，并且要求健康状态为  green, 这可以通过 routing. allocation. require.\_name 指定节点名称实现。如果想要查看节点名称， 可调用“GET \_nodes"  接口相看所有集群节点。 与\_split 接口类似，索引在缩减后的具体分片数量可通过 shrink  接口的 index.

number\_of\_shards  参数设置。但它的值必须与原始分片数量保持整数比例关系， 如果不设置该参数将直接缩减为 1  个分片。如示例所示，缩减后索引分片数量为

2 ，同时还清除了两项配置 :

PUT /splited\_employee/\_settings

"settings": \{

"blocks.write": true

"routing.allocation.require.\_name":"TIAN-PC"

PUT /splited employee/\_shrink/shrinked\_employee?copy\_settings=true

"settings":\{

"index.routing.allocation.require.name": null,

"index.blocks.write": null,

"index.number\_of\_shards" :2

同样地，使用  shrink  接口缩容后会创建新索引  shrinked\_employee,  原索引 和新索引都可以查询到相同的文档数据。

**3、\_reindex**  **接口**

尽管 \_split  接口和  shrink  接口可以对索引分片数量做扩容和缩容，但在分片 数量上有倍数要求，并且分片总量受散列空间( 即  number\_of\_routing\_shards 参数 ) 的限制。如果索引容量超出了散列空间或者有其他特殊要求，则可以按新需求创 建新的索引。Elasticsearch  提供的 \_reindex  接口支持将文档从一个索引重新索引 到到另一个索引中。但显然重新索引在性能上的开销要比 \_split  和 \_shrink  大， 所以尽量不要使用这种办法。\_reindex  接口需要两个参数  source  和  dest, 前者指 明文档来源索引而后者则指明了文档添加的新索引。例如在示例中是将 users  索 引中的文档添加到 users\_copy  索引中 :

POST \_reindex

"source" :\{

"index":"users"

\},

"dest": \{

"index":"users\_copy"

需要注意的是，在重新索引时，不会将原索引的配置信息复制到新索引中。 如果事先没有指定索引配置，重新索引时将根据默认配置创建索引及映射。另外， 使用 reindex  接口必须将索引的 \_ source  字段开启。

**二、缓存相关**

为了提升数据检索时的性能， Elatisearch  为索引提供了三种缓存。 第一种缓存称为节点查询缓存(Node Query Cache),  负责存储节点查询结果。 节点查询缓存是节点级别的，一个节点只有一个缓存，同一节点上的分片共享同 一缓存。 在默认情况下，节点查询缓存是开启的，可通过索引 index. queries. cache. enabled 参数关闭。节点查询缓存默认使用节点内存的  10% 作为缓存容量

上限，可通过  indices. queries. cache\_ size  更改，这个参数是节点的配置而非索 引配置。第二种缓存被称为分片请求缓存(Shard Request Cache) ，负责存储分片接收 到的查询结果。分片请求缓存不会缓存查询结果的 hits  字段，也就是具体的文档

内容，它一般只缓存聚集查询的相关结果。在默认情况下，分片请求缓存也是开 启的，通过索引 index.requests cache. enable  参数关闭。另一种关闭该缓存的办 法，是在调用 search  接口时添加  request. \_cache = false  参数。 分片请求缓存使用的键是作为查询条件 JSON  字符串，所以如果查询条件 JSON 串完全相同，文档的查询几乎可以达到实时。但由于  JSON  属性之间并没有 次序要求，这意味着即使  JSON  描述的是同一个对象，只要它们属性的次序不同 就不能在缓存中命中数据。这点在使用时需要格外注意。 最后一种缓存就是 text  类型字段在开启  fielddata  机制后使用的缓存，它会 将 text  类型字段提取的所有词项全部加载到内存中，以提高使用该字段做排序和 聚集运算的效率。由于 fielddata  是  text  类型对文档值机制的代替，所以这种缓 存机制天然就是开启的且不能关闭。但可通过 indices. Fielddata.cache. size  设置 这个缓存的容量，默认情况下该缓存没有容量上限。 缓存的引入使得文档检索性能得到了提升，但缓存一般会带来两个主要问题: 一是如何保证缓存数据与实际数据的一致;  另一个问题是 当缓存容量超出时如 何清理缓存。 数据一致性问题，Elasticsearch  是通过让缓存与索引刷新频率保持一致实现 的。还记得索引是准实时的吗? 索引默认情况下会以每秒  1  次的频率将文档编入 索引，Elasticsearch  会在索引更新的同时让缓存也失效，这就保证了索引数据与 缓存数据的一致性。缓存数据容量问题则是通过 LRU  的方式，将最近最少使用的 缓存条目清除。同时，Elasticsearch  还提供了一个  cache  接口用于主动清理缓存。

**1、\_refresh**  **接口**

\_refresh  接口用于主动刷新一个或多个索引，将已经添加的文档编入索引以 使它们在检索时可见。在调用该接口时，可以直接调用或与一个或多个索引起使 用， 还可以使用\_all  刷新所有索引。

GET  索引  1/\_refresh

POST \_refresh

GET all/\_refresh

POST  索引  1,  索引  2/\_ refresh

事实上，除了使用  refresh  接口主动刷新索引外，也可以在操作文档时通过 refresh 参数刷新索引。

**2、\_cache**  **接口**

\_cache  接口用于主动清理缓存，在调用该接口时需要在 \_cache  后附加关键 字 clear 。

\_ cache  接口可以清理所有缓存，也可以清理某一索引甚至某一字段的缓存，

还可以只清理某种类型的缓存。例如 :

POST / 索引  1/\_cache /clear?query=true

POST / 索引  1,  索引  2/\_cache /clear?request= true

POST / 索引  1/\_ cache/clear?fielddata =true&fields = notes

在示例中， query 、 request 、 fielddata  参数分别对应于不同的缓存类型，而 fields 参数则用于定义清理哪一个字段的缓存。

**三、查看运行状态**

除此上述接口以外， Elasticsearch  还提供了一组用于查看索引及分片运行情 况的接口，包括\_stat 、 \_shard\_stores  和 \_segments  等。由于它们往往在性能分析 时使用。

**1、\_stats**  **接口**

\_stats  接口用于查看索引上不同操作的统计数据，可以直接请求也可以与索 引名称一起使用。\_stats  接口返回的统计数据非常多，如果只对其中某一组统计 数据感兴趣，可以在\_stats  接口后附加统计名称。 例如以下对  stats  接口的调用 都是正确的:

GET \_stats

GET \_stats/store

GET kibana\_sample\_data\_flights/\_stats

GET kibana\_sample\_data\_flights/\_stats/fielddata

在  stats  接口中可以使用的统计名称及它们的含义见下面，它们在返回结果 中的含义与此相同。

docs  文档总量

store  索引存储量

indexing  索引文档的统计

get GET  查询文档的统计

search \_search  接口检索文档的统计

segments  分段内存的统计

completion completion  统计

frelddata fielddata  机制使用情况统计

flush flush  统计

merge merge  统计

request\_ cache reuqest\_ cache  统计

refresh refresh  统计

warmer warmer  统计

translog

translog  统计

**2、\_segments**  **接口**

\_shard\_stores  接口用于查询索引分片存储情况，而  segments  接口则用于查 看底层 Lucene  的分段情况。这两个接口都只能通过  GET  方法请求，同时都可以 针对一个或多个索引，例如:

GET \_shard\_stores GET /kibana\_sample\_data\_flights/\_shard\_stores

GET \_segments

GET /kibana\_sample\_data\_flights/\_segments/

**四、其他检索接口**

我们前面的检索实际上都是围绕着  search  接口，但实际上  Elasticsearch  还 提供了许多与文档检索有关的接口。比如，如果想要查看索引中满足条件的文档 数量可以使用\_count  接口，如果想要执行一组检索可以使用  msearch  接口，

**1、\_count**  **接口**

Elasticsearch  提供了查看文档总数的 \_ count  接口，可通过  GET  或  POST  方法 请求该接口。在请求该接口的路径上，可以添加索引、映射类型，以限定统计文 档数量的范围。所以在示例中对 count  接口的请求都是正确的 :

GET \_count

POST /kibana\_sample\_data\_logs/\_count

"query": \{

"match":\{

"message": "chrome"

**2、\_msearch**  **接口**

\_msearch  接口，可以在一次接口调用中执行多次查询，可以使用 GET 或 POST 方法请求。请求体每两行为一组视为一个查询，第一行为查询头包含 index 、 search\_type、  preference  和  routing  等基本信息，第二行为查询体包含具体要检 索的内容如 query 、 aggregation  等。例如 :

POST /kibana\_sample\_data\_flights/\_msearch

\{\}

\{"query":\{"match\_all":\{\}\},"from" : 0,"size" : 10 \}

\{\}

\{"query" : \{"match\_all" : \{\}\}\}

\{"index" : "kibana\_sample\_data\_logs" \}

\{"query" : \{"match\_all": \{\}\}\}

在示例中包含了  3  个查询，前两个查询的查询头都是空的，所以默认在请求 路径中指定的 kibana\_sample\_data\_flights  索引中查询 ; 最后一个则在查询头 中指 定了索引为kibana\_sample\_data\_logs,  所以会在 kibana\_sample\_data\_logs  索引中 查询。

**3、\_validate**  **接口**

\_validate  接口用于在不执行查询的情况下，评估一个查询是否合法可执行， 这通常用于验证执行开销比较高的查询。\_validate  接口可通过  GET  或  POST  方法 请求，请求路径中必须要包含\_validate/ query, 也可以在路径中添加索引名称以限 定查询执行的范围。类似\_search  接口。示例 :

POST \_validate/query

"query": \{

"range":\{

"AvgTicketPrice": \{

"gte": 1000,

"lte": 1500

**4、\_field\_caps**  **接口**

\_field\_ caps  接口用于查看某一字段支持的功能， 主要包括字段是否可检索 以及是否可聚集等。需要查看的字段可以通过 URI  参数  fields  设置，虽然可以使 用 GET  或  POST  方法请求。在请求地址中，还可以添加索引名称以限定查询范围。

例如 :

GET \_field\_caps?fields=AvgTicketPrice

POST /kibana\_sample\_data\_logs/\_field\_caps?fields=message,agent

**五、批量接口**

批量操作除了 \_msearch  接口接口以外，还有 \_bulk  接口和 \_mget  接口。

**1、\_bulk**

如果需要批量地对  Elasticsearch  中的文档进行操作，可以使用 \_bulk  接口执 行以提升效率和性能。 \_bulk  接口一组请求体，请求体一般每两个一组，对应种 对文档的操作;  第一个请求体代表操作文档的类型，而第二个请求体则代表操作 文档所需要的参数。但对于某些不需要参数的文档操作来说，则可能只有一个请 求体。操作类型包括  index 、 create 、  delete 、  update  等，其中  index  和  create 都代表创建文档，区别在于当要创建的文档存在时，create  会失败而  index  则可 以变为更新; delete  和  update  则分别代表删除和更新文档。例如 :

POST \_bulk

\{ "index" : \{"\_index": "students","\_id":"10"\}\}

\{ "name" : "smith" \}

\{ "delete" : \{"\_index": "test","\_id":"5"\}\}

\{ "create": \{"\_index": "test","\_id":"11"\}\}

\{ "age" : 30,"name":"Candy" \}

\{ "update" : \{"\_id" :"1","\_index" : "students"\} \}

\{ "doc": \{"age" : "20"\}\}

**2、\_mget**

一条一条的查询，比如说要查询  100  条数据，那么就要发送  100  次网络请求， 这个开销还是很大的，如果批量查询的话，查询 100  条数据，就只要发送  1  次网 络请求，网络请求的性能开销缩减 100  倍。 比如一般的查询是：get /open-soft/\_doc/1

批量查询则是：

GET /\_mget