Elasticsearch（三）-分布式增删改查和搜索

迈不过友情╰ 2022-06-15 23:17 177阅读 0赞

# 分布式增删改查 #

## 路由 ##

### 路由文档到分片 ###

Elasticsearch是如何知道文档属于哪个分片的呢？当你创建一个新文档，它是如何知道是应该存储在分片1还是分片2上的呢？

进程不能是随机的，因为我们将来要检索文档。事实上，它根据一个简单的算法决定：

`shard = hash(routing) % number_of_primary_shards`

routing值是一个任意字符串，它默认是\_id但也可以自定义。这个routing字符串通过哈希函数生成一个数字，然后除以主切片的数量得到一个余数(remainder)，余数的范围永远是0到`number_of_primary_shards - 1`，这个数字就是特定文档所在的分片。

这也解释了为什么主分片的数量只能在创建索引时定义且不能修改：如果主分片的数量在未来改变了，所有先前的路由值就失效了，文档也就永远找不到了

## 分片交换 ##

### 主分片和复制分片如何交互 ###

我们假设有三个节点的集群。它包含一个叫做bblogs的索引并拥有两个主分片。每个主分片有两个复制分片。相同的分片不会放在同一个节点上。

![3-1主分片和复制分片如何交互][3-1]

我们能够发送请求给集群中任意一个节点。每个节点都有能力处理任意请求。每个节点都知道任意文档所在的节点，所以也可以将请求转发到需要的节点。被请求的节点叫做请求节点。

## 新建、索引和删除 ##

### 新建、索引和删除文档 ###

新建、索引和删除请求都是写(write)操作，它们必须在主分片上成功完成才能复制到相关的复制分片上。

![3-2 新建、索引和删除文档][3-2]

在主分片和复制分片上成功新建、索引或删除一个文档必要的顺序步骤：

1.  客户端给Node 1发送新建、索引或删除请求。
2.  节点使用文档的\_id确定文档属于分片0。它转发请求到Node 3，分片0位于这个节点上。
3.  Node 3在主分片上执行请求，如果成功，它转发请求到相应的位于Node 1和Node 2的复制节点上。当所有的复制节点报告成功，Node 3报告成功到请求的节点，请求的节点再报告给客户端。

客户端接收到成功响应的时候，文档的修改已经被应用于主分片和所有的复制分片。你的修改生效了。

有很多可选的请求参数允许你更改这一过程。你可能想牺牲一些安全来提高性能。这一选项很少使用因为Elasticsearch已经足够快，不过为了内容的完整我们将做一些阐述。

### replication ###

复制默认的值是sync。这将导致主分片得到复制分片的成功响应后才返回。

如果你设置replication为async，请求在主分片上被执行后就会返回给客户端。它依旧会转发请求给复制节点，但你将不知道复制节点成功与否。

上面的这个选项不建议使用。默认的sync复制允许Elasticsearch强制反馈传输。async复制可能会因为在不等待其它分片就绪的情况下发送过多的请求而使Elasticsearch过载。

### consistency ###

默认主分片在尝试写入时需要规定数量(quorum)或过半的分片（可以是主节点或复制节点）可用。这是防止数据被写入到错的网络分区。规定的数量计算公式如下：

`int( (primary + number_of_replicas) / 2 ) + 1`

`consistency`允许的值为one（只有一个主分片），all（所有主分片和复制分片）或者默认的quorum或过半分片。

注意number\_of\_replicas是在索引中的的设置，用来定义复制分片的数量，而不是现在活动的复制节点的数量。如果你定义了索引有3个复制节点，那规定数量是：

`int( (primary + 3 replicas) / 2 ) + 1 = 3`

但如果你只有2个节点，那你的活动分片不够规定数量，也就不能索引或删除任何文档。

### timeout ###

当分片副本不足时会怎样？Elasticsearch会等待更多的分片出现。默认等待一分钟。如果需要，你可以设置timeout参数让它终止的更早：100表示100毫秒，30s表示30秒。

> 注意：
> 
> 新索引默认有1个复制分片，这意味着为了满足quorum的要求需要两个活动的分片。当然，这个默认设置将阻止我们在单一节点集群中进行操作。为了避开这个问题，规定数量只有在`number_of_replicas`大于一时才生效

## 检索 ##

### 检索文档 ###

文档能够从主分片或任意一个复制分片被检索。

![3-3检索文档][3-3]

在主分片或复制分片上检索一个文档必要的顺序步骤：

1.  客户端给Node 1发送get请求。
2.  节点使用文档的\_id确定文档属于分片0。分片0对应的复制分片在三个节点上都有。此时，它转发请求到Node 2。
3.  Node 2返回文档(document)给Node 1然后返回给客户端。

对于读请求，为了平衡负载，请求节点会为每个请求选择不同的分片——它会循环所有分片副本。

可能的情况是，一个被索引的文档已经存在于主分片上却还没来得及同步到复制分片上。这时复制分片会报告文档未找到，主分片会成功返回文档。一旦索引请求成功返回给用户，文档则在主分片和复制分片都是可用的。

## 局部更新 ##

### 局部更新文档 ###

update API 结合了之前提到的读和写的模式。

顺序如下图：

![局部更新][SouthEast]

1.  客户端给Node 1发送更新请求。
2.  它转发请求到主分片所在节点Node 3。
3.  Node 3从主分片检索出文档，修改\_source字段的JSON，然后在主分片上重建索引。如果有其他进程修改了文档，它以`retry_on_conflict`设置的次数重复步骤3，都未成功则放弃。
4.  如果Node 3成功更新文档，它同时转发文档的新版本到Node 1和Node 2上的复制节点以重建索引。当所有复制节点报告成功，Node 3返回成功给请求节点，然后返回给客户端。

update API还接受《新建、索引和删除》章节提到的routing、replication、consistency和timout参数。

> **基于文档的复制**
> 
> 当主分片转发更改给复制分片时，并不是转发更新请求，而是转发整个文档的新版本。记住这些修改转发到复制节点是异步的，它们并不能保证到达的顺序与发送相同。如果Elasticsearch转发的仅仅是修改请求，修改的顺序可能是错误的，那得到的就是个损坏的文档。

## 批量请求 ##

### 多文档模式 ###

mget和bulk API与单独的文档类似。差别是请求节点知道每个文档所在的分片。它把多文档请求拆成每个分片的对文档请求，然后转发每个参与的节点。

一旦接收到每个节点的应答，然后整理这些响应组合为一个单独的响应，最后返回给客户端。

![3-5批量请求][3-5]

mget请求检索多个文档的顺序步骤：

1.  客户端向Node 1发送mget请求。
2.  Node 1为每个分片构建一个多条数据检索请求，然后转发到这些请求所需的主分片或复制分片上。当所有回复被接收，Node 1构建响应并返回给客户端。

![3-6mget][]

bulk执行多个create、index、delete和update请求的顺序步骤：

1.  客户端向Node 1发送bulk请求。
2.  Node 1为每个分片构建批量请求，然后转发到这些请求所需的主分片上。
3.  主分片一个接一个的按序执行操作。当一个操作执行完，主分片转发新文档（或者删除部分）给对应的复制节点，然后执行下一个操作。一旦所有复制节点报告所有操作已成功完成，节点就报告success给请求节点，后者(请求节点)整理响应并返回给客户端。

bulk API还可以在最上层使用replication和consistency参数，routing参数则在每个请求的元数据中使用。

# 搜索 #

## 空搜索 ##

### 空搜索 ###

最基本的搜索API表单是空搜索(empty search)，它没有指定任何的查询条件，只返回集群索引中的所有文档：`GET /_search`

返回数据说明：

### hits ###

响应中最重要的部分是hits，它包含了total字段来表示匹配到的文档总数，hits数组还包含了匹配到的前10条数据。

hits数组中的每个结果都包含\_index、\_type和文档的\_id字段，被加入到\_source字段中这意味着在搜索结果中我们将可以直接使用全部文档。

每个节点都有一个\_score字段，这是相关性得分(relevance score)，它衡量了文档与查询的匹配程度。默认的，返回的结果中关联性最大的文档排在首位；

### max\_score ###

指的是所有文档匹配查询中\_score的最大值。

### took ###

告诉我们整个搜索请求花费的毫秒数。

### shards ###

\_shards节点告诉我们参与查询的分片数（total字段），有多少是成功的（successful字段），有多少的是失败的（failed字段）。通常我们不希望分片失败，不过这个有可能发生。如果我们遭受一些重大的故障导致主分片和复制分片都故障，那这个分片的数据将无法响应给搜索请求。这种情况下，Elasticsearch将报告分片failed，但仍将继续返回剩余分片上的结果。

### timeout ###

time\_out值告诉我们查询超时与否。一般的，搜索请求不会超时。如果响应速度比完整的结果更重要，你可以定义timeout参数。`GET /_search?timeout=10ms` Elasticsearch将返回在请求超时前收集到的结果。

> 需要注意的是timeout不会停止执行查询，它仅仅告诉你目前顺利返回结果的节点然后关闭连接。在后台，其他分片可能依旧执行查询，尽管结果已经被发送。

## 多索引和多类别 ##

### 多索引和多类别 ###

搜索一个或几个自定的索引或类型，我们能通过定义URL中的索引或类型达到这个目的

1.  在所有索引的所有类型中搜索
    
    `/_search`
2.  在索引gb的所有类型中搜索
    
    `/gb/_search`
3.  在索引gb和us的所有类型中搜索
    
    `/gb,us/_search`
4.  在以g或u开头的索引的所有类型中搜索
    
    `/g*,u*/_search`
5.  在索引gb的类型user中搜索
    
    `/gb/user/_search`
6.  在索引gb和us的类型为user和tweet中搜索
    
    `/gb,us/user,tweet/_search`
7.  在所有索引的user和tweet中搜索 search types user and tweet in all indices
    
    `/_all/user,tweet/_search`

当你搜索包含单一索引时，Elasticsearch转发搜索请求到这个索引的主分片或每个分片的复制分片上，然后聚集每个分片的结果。搜索包含多个索引也是同样的方式——只不过或有更多的分片被关联。

## 分页 ##

### 分页 ###

和SQL使用LIMIT关键字返回只有一页的结果一样，Elasticsearch接受from和size参数：

size: 结果数，默认10

from: 跳过开始的结果数，默认0

如果你想每页显示5个结果，页码从1到3，那请求如下：

GET /_search?size=5
    GET /_search?size=5&from=5
    GET /_search?size=5&from=10

应该当心分页太深或者一次请求太多的结果。结果在返回前会被排序。但是记住一个搜索请求常常涉及多个分片。每个分片生成自己排好序的结果，它们接着需要集中起来排序以确保整体排序正确。

> **在集群系统中深度分页**
> 
> 为了理解为什么深度分页是有问题的，让我们假设在一个有5个主分片的索引中搜索。当我们请求结果的第一页（结果1到10）时，每个分片产生自己最顶端10个结果然后返回它们给请求节点(requesting node)，它再排序这所有的50个结果以选出顶端的10个结果。
> 
> 现在假设我们请求第1000页——结果10001到10010。工作方式都相同，不同的是每个分片都必须产生顶端的10010个结果。然后请求节点排序这50050个结果并丢弃50040个！
> 
> 你可以看到在分布式系统中，排序结果的花费随着分页的深入而成倍增长。这也是为什么网络搜索引擎中任何语句不能返回多于1000个结果的原因。

## 查询字符串 ##

### 简易搜索 ###

search API有两种表单：一种是“简易版”的查询字符串(query string)将所有参数通过查询字符串定义，另一种版本使用JSON完整的表示请求体(request body)，这种富搜索语言叫做结构化查询语句（DSL）

查询字符串搜索对于在命令行下运行点对点(ad hoc)查询特别有用。例如这个语句查询所有类型为tweet并在tweet字段中包含elasticsearch字符的文档：

`GET /_all/tweet/_search?q=tweet:elasticsearch`

下一个语句查找name字段中包含”john”和tweet字段包含”mary”的结果。实际的查询只需要：

`+name:john +tweet:mary`

但是百分比编码(percent encoding)需要将查询字符串参数变得更加神秘：

`GET /_search?q=%2Bname%3Ajohn+%2Btweet%3Amary`

“+”前缀表示语句匹配条件必须被满足。类似的”-“前缀表示条件必须不被满足。所有条件如果没有+或-表示是可选的:匹配越多，相关的文档就越多。

### \_all字段 ###

返回包含”mary”字符的所有文档的简单搜索：

`GET /_search?q=mary`

在前一个例子中，我们搜索tweet或name字段中包含某个字符的结果。然而，这个语句返回的结果在三个不同的字段中包含”mary”：

1.  用户的名字是“Mary”
2.  “Mary”发的六个推文
3.  针对“@mary”的一个推文

Elasticsearch是如何设法找到三个不同字段的结果的？

当你索引一个文档，Elasticsearch把所有字符串字段值连接起来放在一个大字符串中，它被索引为一个特殊的字段\_all。例如，当索引这个文档：

{
        "tweet":    "However did I manage before Elasticsearch?",
        "date":     "2014-09-14",
        "name":     "Mary Jones",
        "user_id":  1 }

这好比我们增加了一个叫做\_all的额外字段值：

`"However did I manage before Elasticsearch? 2014-09-14 Mary Jones 1"`

若没有指定字段，查询字符串搜索（即q=xxx）使用\_all字段搜索。

### 更复杂的语句 ###

下一个搜索推特的语句：

\_all field

1.  name字段包含”mary”或”john”
2.  date晚于2014-09-10
3.  \_all字段包含”aggregations”或”geo”

`+name:(mary john) +date:>2014-09-10 +(aggregations geo)`

查询字符串搜索允许任意用户在索引中任何一个字段上运行潜在的慢查询语句，可能暴露私有信息甚至使你的集群瘫痪。

--------------------

参考资料：  
Elasticsearch权威指南  
备注：  
转载请注明出处：[http://blog.csdn.net/wsyw126/article/details/70946129][http_blog.csdn.net_wsyw126_article_details_70946129]  
作者：WSYW126

[3-1]: /images/20220616/651deb97643044c7a1a3182e7e9ca49f.png
[3-2]: /images/20220616/db08995c25a4485d84f6983afeab0ff5.png
[3-3]: /images/20220616/45a90ea478154e3cb7ad33173efb8ec4.png
[SouthEast]: /images/20220616/a32f0bca930b40f8bf4dbaf486ff955f.png
[3-5]: /images/20220616/9506b59670be4b2bb79d92ab4964edf5.png
[3-6mget]: /images/20220616/5630c9ea543d4e058ebc58e714fc5594.png
[http_blog.csdn.net_wsyw126_article_details_70946129]: http://blog.csdn.net/wsyw126/article/details/70946129