文档API - shuiyuebingdian/ElasticSearch GitHub Wiki

本部分首先简要介绍Elasticsearch的数据复制模型，然后详细介绍以下CRUD API：

单个文档 APIs

  • Index API
  • Get API
  • Delete API
  • Update API

多文档 API

  • Multi-Get API
  • Bulk API
  • Delete By Query API
  • Update By Query API
  • Reindex API

所有CRUD API都是单索引API。该index参数接受单个索引名称，或alias指向单个索引的。

读写文件

介绍

Elasticsearch中的每个索引都分为多个碎片 ，每个碎片可以有多个副本。这些副本称为复制组，添加或删除文档时必须保持同步。如果我们不这样做，那么从一个副本中读取的结果将与从另一个副本中读取的结果截然不同。使分片副本保持同步并提供对它们的读取服务的过程就是我们所说的数据复制模型。

Elasticsearch的数据复制模型基于主备份模型，并且在Microsoft Research 的PacificA论文中进行了很好的描述 。该模型基于复制组中的一个副本作为主要分片。其他副本称为副本碎片。主目录充当所有索引操作的主要入口点。它负责验证它们并确保它们是正确的。一旦主数据库接受了索引操作，主数据库还负责将操作复制到其他副本。

本部分的目的是从总体上概述Elasticsearch复制模型，并讨论它对读写操作之间各种交互的影响。

基本写模型

首先使用路由（通常基于文档ID）将Elasticsearch中的每个索引操作解析为一个复制组。确定复制组后，该操作将在内部转发到该组的当前主分片。主分片负责验证操作并将其转发到其他副本。由于副本可以脱机，因此不需要主副本复制到所有副本。相反，Elasticsearch维护应接收该操作的分片副本列表。此列表称为同步副本并由主节点维护。顾名思义，这些是保证已处理所有已被用户确认的索引和删除操作的“良好”分片副本的集合。主数据库负责维护此不变性，因此必须将所有操作复制到此集中的每个副本。

主要分片遵循以下基本流程：

  1. 验证传入的操作，如果结构上无效，则将其拒绝（例如：在对象字段中应有数字）
  2. 在本地执行操作，即索引或删除相关文档。这还将验证字段的内容并在需要时拒绝（例如：关键字值对于在Lucene中建立索引而言太长）。
  3. 将操作转发到当前同步副本集中的每个副本。如果有多个副本，则这是并行进行的。
  4. 一旦所有副本都成功执行了操作并响应了主服务器，主服务器便向客户端确认请求的成功完成。

故障处理

在建立索引期间，许多事情可能会出错—磁盘可能会损坏，节点之间可能会断开连接，或者某些配置错误可能会导致副本操作失败，尽管该副本在主数据库上成功执行。这些很少见，但主要的必须对此做出回应。

在主要节点本身发生故障的情况下，托管主要节点的节点将向主机发送有关此消息。索引操作将等待（默认情况下最多1分钟），等待主数据库将其中一个副本提升为新的主数据库。然后，该操作将转发到新的主数据库进行处理。请注意，主节点还监视节点的运行状况，并可以决定主动降级主节点。当持有主节点的节点由于网络问题而与群集隔离时，通常会发生这种情况。有关更多详细信息，请参见此处。

一旦在主数据库上成功执行了该操作，当在副本分片上执行主数据库时，主数据库就必须处理潜在的故障。这可能是由于副本上的实际故障或由于网络问题导致操作无法到达副本​​（或阻止副本进行响应）引起的。所有这些都具有相同的最终结果：作为同步副本集一部分的副本错过了将要确认的操作。为了避免违反不变式，主数据库向主数据库发送一条消息，请求从同步副本集中删除有问题的分片。只有主服务器确认已清除分片后，主服务器才确认该操作。

在将操作转发到副本时，主要数据库将使用副本来验证它仍然是活动的主要数据库。如果主服务器由于网络分区（或较长的GC）而被隔离，它可能会继续处理传入的索引操作，然后再意识到它已被降级。来自陈旧的主服务器的操作将被副本服务器拒绝。当主服务器收到来自副本的响应，因为它不再是主服务器而拒绝了它的请求时，它将与主服务器联系，并得知已被替换。然后，该操作将路由到新的主数据库。

如果没有副本会怎样？

这是一个有效的情况，可能由于索引配置而发生，或者仅由于所有副本都已失败而发生。在那种情况下，主要是没有任何外部验证的处理操作，这似乎是有问题的。另一方面，主节点不能独自使其他分片失效，而可以要求主节点代表它这样做。这意味着主服务器知道主服务器是唯一的单个良好副本。因此，我们保证主服务器不会将任何其他（过时的）分片副本提升为新的主副本，并且索引到该主副本的任何操作都不会丢失。当然，由于此时我们仅使用数据的单个副本运行，因此物理硬件问题可能会导致数据丢失。有关某些缓解措施，请参阅等待活动碎片。

基本读取模型

通过ID进行Elasticsearch中的读取可以是非常轻量级的查找，也可以是具有复杂聚合的繁重搜索请求，而这些聚合需要占用不小的CPU能力。主备份模型的优点之一是，它使所有分片副本保持相同（运行中的操作除外）。因此，单个同步副本足以满足读取请求。

当节点接收到读取请求时，该节点负责将其转发到持有相关分片的节点，整理响应并响应客户端。我们将该节点称为该请求的协调节点。基本流程如下：

  1. 解决对相关分片的读取请求。请注意，由于大多数搜索将发送到一个或多个索引，因此它们通常需要从多个分片中读取，每个分片代表数据的不同子集。
  2. 从分片复制组中选择每个相关分片的活动副本。这可以是主副本或副本副本。默认情况下，Elasticsearch将仅在分片副本之间进行循环。
  3. 将分片级别的读取请求发送到所选副本。
  4. 结合结果并做出回应。请注意，在通过ID查找get的情况下，只有一个分片是相关的，可以跳过此步骤。

故障处理

当分片无法响应读取请求时，协调节点将从同一复制组中选择另一个副本，并将分片级别搜索请求发送到该副本。重复性故障可能导致没有可用的碎片副本。在某些情况下，例如_search，Elasticsearch宁愿快速响应，尽管会有部分结果，而不是等待问题得以解决（部分结果显示在_shards响应的标题中）。

一些简单的含义

这些基本流程中的每一个都确定Elasticsearch作为读取和写入系统的行为。此外，由于可以同时执行读取和写入请求，所以这两个基本流程相互交互。这具有一些固有的含义：

高效阅读
在正常操作下，每个读取操作对每个相关复制组执行一次。仅在失败情况下，同一分片的多个副本才执行相同的搜索。
读取未确认数据
由于主要对象首先在本地建立索引，然后复制请求，因此并发读取可能已经在确认更改之前就已经看到了更改。
默认为两个副本
该模型可以容错，同时仅保留两个数据副本。这与基于仲裁的系统相反，在该系统中，容错的最小副本数为3。

失败 在失败下，可能发生以下情况：

单个分片可能会减慢索引编制速度
因为主数据库在每次操作期间都等待同步副本集中的所有副本，所以单个慢速分片可以降低整个复制组的速度。这是我们为上述读取效率所付出的代价。当然，单个慢速碎片也会减慢已路由到它的不幸的搜索。
脏读
隔离的主数据库可以公开不会被确认的写入。这是由于以下事实造成的：隔离的主数据库仅会在将请求发送到其副本时或到达主服务器时才意识到它是隔离的。到那时，该操作已被索引到主操作中，并且可以通过并发读取来读取。Elasticsearch通过每秒对主机进行一次ping操作（默认情况下）并在不知道主机的情况下拒绝索引操作来减轻这种风险。

冰山一角

本文档提供了有关Elasticsearch如何处理数据的高级概述。当然，引擎盖下还有很多事情要做。诸如主要术语，集群状态发布和主选举之类的事情都在保持该系统正确运行中起作用。本文档也未涵盖已知和重要的错误（已关闭和已打开）。我们认识到GitHub很难跟上。为了帮助人们掌握这些信息，我们 在我们的网站上维护了专门的弹性页面。我们强烈建议阅读。