Document APIs

本节首先简要介绍Elasticsearch的数据复制模型，而后详细描述如下CRUD API：

Single document APIs

Index API
Get API
Delete API
Update API

Multi-document APIs

Multi Get API
Bulk API
Delete By Query API
Update By Query API
Reindex API
注意：全部CRUD API都是单索引API。 index参数接受单个索引名称或指向单个索引的别名。

读取和写入文档

介绍

Elasticsearch中的每一个索引会分红多个分片，每一个分片能够有多个副本。 这些副本被称为复制组（replication group），在添加或删除文档时必须保持同步。 不然会致使从不一样的副本查询出来的结果不一致。 保持分片副本同步并提供读取操做的过程就是咱们所说的数据复制模型（data replication model）。

Elasticsearch的数据复制模型基于primary-backup模型，在微软研究院的PacificA论文中有很好的描述。
该模型基于复制组的一个副本，该副本充当主分片（primary shard）。其余副本称为副本分片（replica shards）。主分片是全部索引操做的主要入口点，负责校验并确保操做是正确的。一旦索引操做被主分片接受，主分片也负责将操做复制到其余副本。

本节的目的是高度概述Elasticsearch复制模型，并讨论它对写入和读取操做之间各类交互的影响。

基本写入模型

Elasticsearch中的每一个索引操做首先使用路由（一般基于文档ID）解析到对应的复制组。 一旦肯定了复制组，该操做就会在内部转发到组的当前主分片。 主分片负责校验操做并将其转发给其余副本。 因为副本可能脱机，所以主分片不须要把该操做复制到全部副本。相反，Elasticsearch维护应该接收操做的分片副本列表。 该列表称为同步副本（in-sync copies），由主节点（master node）维护。 顾名思义，这是一组“好”的分片副本，保证已经处理了全部索引和删除操做。 主分片负责维护此不变量（前面说同步副本由master维护。这里又说由primary维护，困惑），所以必须将全部操做复制到此集合中的每一个副本。

主分片遵循如下基本流程：
验证传入操做，拒绝结构无效的操做(例如：传入一个对象字段，但指望的是一个数字)
在本地执行操做，即索引或删除相关文档， 这也将验证字段的内容并在须要时拒绝（例如：关键字值在Lucene中索引太长）。
将操做转发到当前同步副本集中的每一个副本。 若有多个副本，会并行完成。
一旦全部副本都成功执行操做并响应给了主分片，主分片就会确认已成功地完成了客户端的请求。

失败处理
索引期间不少事情均可能出错 --磁盘可能损坏，节点可能互相断开链接，或者某些配置错误可能致使某个副本上的操做失败，尽管它在主分片上成功了。 这些并不常见，但主分片仍是要对它们作出回应。

主分片自己发生故障的时，主分片所在的节点将向master（主节点）发送一条消息。 该索引操做将等待（默认状况下最多1分钟），以便maser将其中一个副本提高为新的主分片。 该操做将被转发到新的主分片进行处理。 请注意，master还监视节点的运行情况，并可能决定主动降级主分片。好比网络问题，持有主分片的节点与集群隔离时，一般会发生这种状况。更多详情请看这里。

一旦在主分片（primary）上成功执行了操做，在副本分片（replica shards）上执行时，主分片（primary）还需处理潜在的失败，失败可能来源于：

• 在副本上执行失败了
• 因为网络问题副本未接收到操做(或副本的响应没法接收)。

全部执行失败的这些分片具备相同的结果：一个副本是同步复制集（in-sync replica set）的一部分，若是错过了即将被确认的操做。为了不违反不变量，主分片会向主节点（master）发送一条消息，请求将有问题的碎片从同步复制集中删除。只有主节点（master）确认移除分片后，主分片（primary）才会确认操做。请注意，主节点（master）还会指示另外一个节点开始构建新的分片副本，以便将系统恢复到健康状态。

在将操做转发给副本时，主分片将使用该副原本验证它是否仍然处于活动状态。若是主分片因为网络问题（或长时间的GC）而被隔离，它可能会继续处理传入的索引操做，而后才意识到本身已被降级。已降级的主分片接收的操做不会被副本认可。当它收到来自副本拒绝的响应后，那么它将与主节点（master）联系并知道它已被替换。而后该操做被路由到新的主分片。

假如没有副本会发生什么呢？
这是一个有效的场景，多是因为索引配置，或者仅仅是由于全部的副本都失败了。在这种状况下，主分片处理操做，而不须要任何外部验证，这可能看起来有问题。
另外一方面，主分片不能舍弃其余分片，但会请求主节点（master）表明它执行此操做。这意味着主节点（master）知道主分片是惟一的好的副本。咱们会所以保证主节点（master）不会将任何其余(过期的)分片副本提高为一个新的主分片，而且任何索引到主分片的操做都不会丢失。固然，物理硬件问题可能致使数据丢失。请参阅 Wait For Active Shards 。

基本读模型

Elasticsearch中的读取操做能够经过ID进行很是轻量级的查找，也能够经过复杂的聚合进行重量级的搜索请求，这些请求会占用大量的CPU资源。主从复制（primary-backup）的一个优势是它能够保持全部分片副本一致(with the exception of in-flight operations)。所以，单个同步副本足以知足读取请求。

当某个节点收到读取请求时，该节点负责将其转发到相关分片的节点，整理响应并响应客户端。咱们称该节点为该请求的协调节点（coordinating node）。基本流程以下：

解析读请求到相关的分片。注意，因为大多数搜索将被发送到一个或多个索引，它们一般须要从多个分片读取，每一个分片表示不一样的数据子集。
从分片复制组中选择每一个相关分片的活动副本。这能够是主分片或副本。默认状况下，Elasticsearch只会在分片的副本间循环。
将分片级别的读请求发送到所选副本。
结合结果并作出回应。请注意，在经过ID查找的状况下，只有一个分片是相关的，该步骤能够被跳过。

失败处理
当分片没法响应读取请求时，协调节点将从同一复制组中选择另外一个副本，并将分片级别搜索请求发送到该副本。 重复性故障可能致使没有可用的分片副本。 在某些状况下，好比_search，Elasticsearch会更倾向于快速响应，可能会只有部分结果，而不是等待问题获得解决（部分结果在响应的_shards头中）。

一些简单的含义

这些基本流程中的每个都决定了Elasticsearch做为读写系统的行为。 此外，因为读取和写入请求能够同时执行，所以这两个基本流程相互做用。 这有几个内在的含义：

有效的读取
在正常操做下，每一个相关复制组执行一次读取操做。 只有在失败状况下，同一个分片的多个副本才会执行相同的搜索。
读未确认
因为主分片首先在本地创建索引，而后复制请求，所以并发读取可能在未确认的状况下就被读取。
默认两个副本
该模型能够容错，同时只保留两个数据副本。 这与quorum-based 系统相反，该系统容错的最小副本数为3。

Failures

在失败的状况下，如下是可能的：

单个分片会减慢索引
因为主分片在每次操做期间都会等待设置同步副本中的全部副本，所以单个慢分片会减慢整个复制组的速度。 这是咱们为上述读取效率付出的代价。 固然，一个缓慢的分片也会减慢已经发送给它的搜索。
脏读
一个孤立的主分片能够暴露不被确认的写入。 这是因为一个孤立的主分片只有在向其副本发送请求或向主节点（master）发送请求时才会将其隔离。 此时该操做已经被索引到主分片，并能够被并发读取。 Elasticsearch经过每秒（默认状况下）对主节点（master）执行ping操做，在没有发现主节点（master）存在的状况下拒绝索引操做来减轻风险。

冰山一角
本文档提供了Elasticsearch如何处理数据的高级概述。 固然，还有不少事情要作。 诸如primary terms， cluster state publishing 和 master election 等都在保持系统正常运行方面发挥了做用。 本文档也不涵盖已知和重要的错误（包括已关闭和打开）。 咱们认识到GitHub很难跟上。 为了帮助人们保持最佳状态，在咱们的网站上维护了专用的弹性页面。 强烈建议你阅读它。

官方文档：https://www.elastic.co/guide/en/elasticsearch/reference/current/docs-replication.html