Document APIs之数据模型

最新推荐文章于 2024-06-05 10:35:21 发布

limboys

最新推荐文章于 2024-06-05 10:35:21 发布

阅读量157

点赞数

分类专栏： elasticsearch 文章标签： Document API 数据模型

elasticsearch 专栏收录该内容

27 篇文章 0 订阅

订阅专栏

Document APIs

本节首先简要介绍Elasticsearch的数据复制模型，然后详细描述以下CRUD api:

单文档的APIs:

多文档 APIs

所有CRUD api都是单索引api。索引参数接受单个索引名，或指向单个索引的别名。

数据复制模型

Elasticsearch中的每个索引都分为分片(主分片) ，每个分片(主分片)可以有多个副本分片。这些副本分片组合为” replication group”，在添加或删除文档时必须保持与主分片同步。如果我们不这样做，从一个副本中读取将导致与从另一个副本中读取的数据会不一致。保持主分片和副本分片之间的同步并从中提供读取的过程就是我们所说的数据复制模型

Elasticsearch的数据复制模型基于primary-backup model （主备份模型）。该模型基于从replication group中复制一个副本，该分片充当主分片,其他分片称为副本分片。主分片要作为所有索引操作的主要入口点。它负责验证它们并确保它们是正确的。一旦主分片接受了索引操作，主分片还将负责复制该操作到它的副本分片上。

本节的目的是对Elasticsearch复制模型进行高层次的概述，并讨论它对写操作和读操作之间的各种交互的影响。

基本的写入操作

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

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

验证传入操作并在结构无效时拒绝它（例如：对”object”字段指定一个数字值）
索引或删除相关文档操作时,将验证字段的内容并在需要时拒绝（例如：关键字值太长，无法在Lucene中进行索引）。
将操作转发到当前同步副本集中的每个副本。如果有多个副本，则这是并行完成的。
一旦所有副本成功执行了操作并响应主分片，主分片把请求成功执行的信息返回给用户。

故障处理

在索引创建过程中可能会出现许多问题 - 磁盘可能会损坏，节点可能会相互断开连接，或者某些配置错误可能会导致复制数据到副本分片上的操作失败，尽管它在主分片上操作成功。这种情况并不常见，但是主分片必须对这些错误信息做出响应。

在主节点本身失败的情况下，承载主分片的节点将向master节点发送关于它的消息，索引操作将等待（默认情况下最多1分钟），以便通过master节点提升一个副本分片为主分片。新的操作请求会被转发给新的主分片处理。注意master节点还会监控节点的运行状况，并可能决定主动降级主分片, 这通常发生在主分片所在的节点和集群失去联系的时候

一旦在主分片上执行的操作成功，该主分片就必须处理在副本分片上发生的潜在故障。这可能是由副本分片上的实际故障或由于网络阻塞导致导致主分片无法转发操作到副本分片（或者副本分片无法返回结果给主分片）引起的。所有这些都具有相同的最终结果：作为in-sync replica set (同步副本集)的一部分的副本丢失了即将要确认的操作。为了避免违反不变性，主分片向master节点发送消息，请求从in-sync replica set中删除有问题的分片。只有在主分片在确认移除该分片后，主分片才会确认操作。Master节点还会指导另外一个节点建立新的分片副本,以便将集群恢复为健康状态

在将请求转发到副本分片时，主分片将使用副本分片来验证它是否仍然是一个活跃的主分片。如果主分片由于网络分区（或长GC）而被隔离，在它被降级之前它会继续处理传入的索引操作。这时来自陈旧的主分片的操作将会被副本分片拒绝。当主分片接收到来自副本分片拒绝请求的响应(因为它不再是主分片)，那么主分片将向Master节点发送请求并得知它已经被替换。新的请求随后将路由到新的主分片上。

如果没有副本会发生什么？

这是一种有效的场景，可能是由于索引配置，也可能只是因为所有副本都失效了。在这种情况下，将导致主分片没有任何外部验证所要处理操作，这可能会有问题。在另一方面，主分片不能让它的副本分片失效，而是请求master代表自己让副本分片失效。意味着master将知道主分片是目前唯一存活分片。因此，master将不会让任何其他分片副本(失效的)提升为新的分片，并且不会丢失任何索引到主分片的操作。当然，由于此时我们只使用数据的单一节点主分片上运行，物理硬件问题可能会导致数据丢失。

基本的读入操作

Elasticsearch可以通过查询ID实现非常轻量级的查找，也可以是具有复杂聚合的大量搜索请求，这些聚合请求会占用大量的CPU负载。主备份模型的一个优点是它使所有分片副本保持一致（除了正在进行的操作）。因此，单个同步副本足以提供读取请求。

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

将读取请求解析为相关分片。请注意，由于大多数搜索将被发送到一个或多个索引，因此它们通常需要从多个分片中读取，每个分片代表数据的不同子集。
从replication group中选择每个相关分片的active分片。这可以是主分片或副本分片。默认情况下，Elasticsearch将使用round-robin随机轮询算法简单地将请求在主分片以及其所有副本分片中循环,实现负载均衡机制。
发送一个分片级别的读取请求发送到所选分片中。
协调节点合并多个分片的结果并反馈给客户端。请注意，在通过ID查找的情况下，只有一个分片是相关的，可以跳过此步骤。

故障处理

如果当前选中分片不能响应一个读请求,那么协调节点会从replication group中选择另一个分片并发送请求到该分片代替不可用的分片。如果没有可用的分片时,重复请求后将失败。

为了确保快速响应，如果一个或多个碎片失败，以下api将以部分结果响应:

Search、Multi Search、Bulk、Multi Get

包含部分结果的响应仍然提供一个200 OK HTTP状态码。分片故障由响应头的timed_out和_shards字段表示。

一些简单的含义

每一个这样的基础流决定了 Elasticsearch 作为一个系统在读和写之间是如何表现的。此外，由于可以同时执行读写请求，所以这两个基本流彼此相互作用。这有一些固有的含义 :

Efficient reads（高效读取）

在正常操作下，每个读操作为每个相关replication group执行一次。只有在故障条件下，同一个分片的多个副本才会执行相同的搜索。

Read unacknowledged

由于主分片首先在本地进行索引，然后复制请求，所以并发读取可以在确认更改之前就已经看到了更改。

Two copies by default

该模型可以只保留两个数据副本来保证容错。这与基于 quorum-based 的系统形成对比，后者容错的最小副本数为 3。

Failures故障

在故障的情况下，以下情况是可能的:

A single shard can slow down indexing(单个分片可以降低索引的速度)

由于主分片在每次操作期间都要等待同步复制集中的所有副本，因此一个慢速分片可能会减慢整个replication group的速度。这是我们为上面提到的读取效率所付出的代价。当然，一个单一的慢分片也会减慢已经被路由到它的不幸的搜索。

Dirty reads（脏读）

隔离的主分片可以暴露无法识别的写入,因为被隔离的主分片只有向其副本分片发送请求或者向master发送请求才会意识到它是被隔离的。此时,操作已经索引到主分片中,并且在并发请求中可以被用来读取。Elasticsearch为减轻这种风险,默认情况每秒ping一次master,如果没有主分片被master所知, 则拒绝索引操作。