Elasticsearch 分布式文档存储

这篇具有很好参考价值的文章主要介绍了Elasticsearch 分布式文档存储。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

Elasticsearch 分布式文档存储

路由一个文档到一个分片中

当索引一个文档的时候,文档会被存储到一个主分片中。 Elasticsearch 如何知道一个文档应该存放到哪个分片中呢?当我们创建文档时,它如何决定这个文档应当被存储在分片 1 还是分片 2 中呢?

首先这肯定不会是随机的,否则将来要获取文档的时候我们就不知道从何处寻找了。实际上,这个过程是根据下面这个公式决定的:

shard = hash(routing) % number_of_primary_shards

routing 是一个可变值,默认是文档的 _id ,也可以设置成一个自定义的值。 routing 通过 hash 函数生成一个数字,然后这个数字再除以 number_of_primary_shards (主分片的数量)后得到 余数 。这个分布在 0 到 number_of_primary_shards-1 之间的余数,就是我们所寻求的文档所在分片的位置。

这就解释了为什么我们要在创建索引的时候就确定好主分片的数量 并且永远不会改变这个数量:因为如果数量变化了,那么所有之前路由的值都会无效,文档也再也找不到了。

你可能觉得由于 Elasticsearch 主分片数量是固定的会使索引难以进行扩容。实际上当你需要时有很多技巧可以轻松实现扩容。我们将会在扩容设计一章中提到更多有关水平扩展的内容。

所有的文档 API( get 、 index 、 delete 、 bulk 、 update 以及 mget )都接受一个叫做 routing 的路由参数 ,通过这个参数我们可以自定义文档到分片的映射。一个自定义的路由参数可以用来确保所有相关的文档——例如所有属于同一个用户的文档——都被存储到同一个分片中。我们也会在扩容设计这一章中详细讨论为什么会有这样一种需求。

主分片和副本分片如何交互

为了说明目的, 我们 假设有一个集群由三个节点组成。 它包含一个叫 blogs 的索引,有两个主分片,每个主分片有两个副本分片。相同分片的副本不会放在同一节点,所以我们的集群如下图所示。

elasticsearch分片存储,数据存储,elasticsearch,分布式,大数据

我们可以发送请求到集群中的任一节点。 每个节点都有能力处理任意请求。 每个节点都知道集群中任一文档位置,所以可以直接将请求转发到需要的节点上。 在下面的例子中,将所有的请求发送到 Node 1 ,我们将其称为 协调节点(coordinating node) 。

当发送请求的时候, 为了扩展负载,更好的做法是轮询集群中所有的节点。

新建、索引和删除文档

新建、索引和删除 请求都是 写 操作, 必须在主分片上面完成之后才能被复制到相关的副本分片,如下图所示

elasticsearch分片存储,数据存储,elasticsearch,分布式,大数据

以下是在主副分片和任何副本分片上面 成功新建,索引和删除文档所需要的步骤顺序:

  1. 客户端向 Node 1 发送新建、索引或者删除请求。
  2. 节点使用文档的 _id 确定文档属于分片 0 。请求会被转发到 Node 3,因为分片 0 的主分片目前被分配在 Node 3 上。
  3. Node 3 在主分片上面执行请求。如果成功了,它将请求并行转发到 Node 1Node 2 的副本分片上。一旦所有的副本分片都报告成功, Node 3 将向协调节点报告成功,协调节点向客户端报告成功。

在客户端收到成功响应时,文档变更已经在主分片和所有副本分片执行完成,变更是安全的。

有一些可选的请求参数允许您影响这个过程,可能以数据安全为代价提升性能。这些选项很少使用,因为Elasticsearch已经很快,但是为了完整起见,在这里阐述如下:

consistency

consistency,即一致性。在默认设置下,即使仅仅是在试图执行一个_写_操作之前,主分片都会要求 必须要有 规定数量(quorum)(或者换种说法,也即必须要有大多数)的分片副本处于活跃可用状态,才会去执行_写_操作(其中分片副本可以是主分片或者副本分片)。这是为了避免在发生网络分区故障(network partition)的时候进行_写_操作,进而导致数据不一致。_规定数量_即:

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

consistency 参数的值可以设为 one (只要主分片状态 ok 就允许执行_写_操作),all(必须要主分片和所有副本分片的状态没问题才允许执行_写_操作), 或 quorum 。默认值为 quorum , 即大多数的分片副本状态没问题就允许执行_写_操作。

注意,规定数量 的计算公式中 number_of_replicas 指的是在索引设置中的设定副本分片数,而不是指当前处理活动状态的副本分片数。如果你的索引设置中指定了当前索引拥有三个副本分片,那规定数量的计算结果即:

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

如果此时你只启动两个节点,那么处于活跃状态的分片副本数量就达不到规定数量,也因此您将无法索引和删除任何文档。

timeout

如果没有足够的副本分片会发生什么? Elasticsearch会等待,希望更多的分片出现。默认情况下,它最多等待1分钟。 如果你需要,你可以使用 timeout 参数 使它更早终止:

  • 100 是 100毫秒
  • 30s 是30秒

新索引默认有 1 个副本分片,这意味着为满足 规定数量 应该 需要两个活动的分片副本。 但是,这些默认的设置会阻止我们在单一节点上做任何事情。为了避免这个问题,要求只有当 number_of_replicas 大于1的时候,规定数量才会执行。

取回一个文档

可以从主分片或者从其它任意副本分片检索文档 ,如下图所示

elasticsearch分片存储,数据存储,elasticsearch,分布式,大数据

以下是从主分片或者副本分片检索文档的步骤顺序:

  • 1、客户端向 Node 1 发送获取请求。
  • 2、节点使用文档的 _id 来确定文档属于分片 0 。分片 0 的副本分片存在于所有的三个节点上。 在这种情况下,它将请求转发到 Node 2
  • 3、Node 2 将文档返回给 Node 1 ,然后将文档返回给客户端。

在处理读取请求时,协调结点在每次请求的时候都会通过轮询所有的副本分片来达到负载均衡。

在文档被检索时,已经被索引的文档可能已经存在于主分片上但是还没有复制到副本分片。 在这种情况下,副本分片可能会报告文档不存在,但是主分片可能成功返回文档。 一旦索引请求成功返回给用户,文档在主分片和副本分片都是可用的。

局部更新文档

update API 结合了先前说明的读取和写入模式。

elasticsearch分片存储,数据存储,elasticsearch,分布式,大数据

以下是部分更新一个文档的步骤:

  1. 客户端向 Node 1 发送更新请求。
  2. 它将请求转发到主分片所在的 Node 3 。
  3. Node 3 从主分片检索文档,修改 _source 字段中的 JSON ,并且尝试重新索引主分片的文档。 如果文档已经被另一个进程修改,它会重试步骤 3 ,超过 retry_on_conflict 次后放弃。
  4. 如果 Node 3 成功地更新文档,它将新版本的文档并行转发到 Node 1 和 Node 2 上的副本分片,重新建立索引。 一旦所有副本分片都返回成功, Node 3 向协调节点也返回成功,协调节点向客户端返回成功。

update API 还接受在 新建、索引和删除文档 章节中介绍的 routingreplicationconsistencytimeout 参数。

基于文档的复制

当主分片把更改转发到副本分片时, 它不会转发更新请求。 相反,它转发完整文档的新版本。请记住,这些更改将会异步转发到副本分片,并且不能保证它们以发送它们相同的顺序到达。 如果Elasticsearch仅转发更改请求,则可能以错误的顺序应用更改,导致得到损坏的文档。

多文档模式

mgetbulk API 的模式类似于单文档模式。区别在于协调节点知道每个文档存在于哪个分片中。 它将整个多文档请求分解成 每个分片 的多文档请求,并且将这些请求并行转发到每个参与节点。

协调节点一旦收到来自每个节点的应答,就将每个节点的响应收集整理成单个响应,返回给客户端,如图所示:

elasticsearch分片存储,数据存储,elasticsearch,分布式,大数据

以下是使用单个 mget 请求取回多个文档所需的步骤顺序:

  1. 客户端向 Node 1 发送 mget 请求。
  2. Node 1 为每个分片构建多文档获取请求,然后并行转发这些请求到托管在每个所需的主分片或者副本分片的节点上。一旦收到所有答复, Node 1 构建响应并将其返回给客户端。

可以对 docs 数组中每个文档设置 routing 参数。

bulk API, 允许在单个批量请求中执行多个创建、索引、删除和更新请求。

elasticsearch分片存储,数据存储,elasticsearch,分布式,大数据

bulk API 按如下步骤顺序执行:

  1. 客户端向 Node 1 发送 bulk 请求。
  2. Node 1 为每个节点创建一个批量请求,并将这些请求并行转发到每个包含主分片的节点主机。
  3. 主分片一个接一个按顺序执行每个操作。当每个操作成功时,主分片并行转发新文档(或删除)到副本分片,然后执行下一个操作。 一旦所有的副本分片报告所有操作成功,该节点将向协调节点报告成功,协调节点将这些响应收集整理并返回给客户端。

bulk API 还可以在整个批量请求的最顶层使用 consistency 参数,以及在每个请求中的元数据中使用 routing 参数。文章来源地址https://www.toymoban.com/news/detail-841431.html

到了这里,关于Elasticsearch 分布式文档存储的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • elasticsearch(ES)分布式搜索引擎03——(RestClient查询文档,ES旅游案例实战)

    文档的查询同样适用昨天学习的 RestHighLevelClient对象,基本步骤包括: 1)准备Request对象 2)准备请求参数 3)发起请求 4)解析响应 我们以match_all查询为例 3.1.1.发起查询请求 代码解读: 第一步,创建 SearchRequest 对象,指定索引库名 第二步,利用 request.source() 构建DSL,DSL中可

    2024年02月07日
    浏览(49)
  • elasticsearch(ES)分布式搜索引擎01——(初识ES,索引库操作和文档操作,RestClient操作索引库和文档)

    1.1.1.elasticsearch的作用 elasticsearch是一款非常强大的开源搜索引擎,具备非常多强大功能,可以帮助我们从海量数据中快速找到需要的内容 1.1.2.ELK技术栈 elasticsearch结合kibana、Logstash、Beats,也就是elastic stack(ELK)。被广泛应用在日志数据分析、实时监控等领域: 而elasticsearc

    2024年02月07日
    浏览(60)
  • 分布式搜索引擎ElasticSearch——深入elasticSearch

    聚合的分类 DSL实现Bucket聚合 DSL实现Metric聚合 RestAPI实现聚合 https://github.com/medcl/elasticsearch-analysis-pinyin DSL实现自动补全查询 Completion Suggester 修改酒店索引库数据结构 RestAPI实现自动补全查询 实现酒店搜索页面输入框的自动补全 数据同步思路分析 利用MQ实现mysql与elasticsearch数

    2024年01月17日
    浏览(46)
  • 分布式搜索——Elasticsearch

    Elasticsearch是一款非常强大的开源搜索引擎,具备非常多强大功能,可以帮助用户从海量数据中快速找到需要的内容。例如:在GitHub搜索代码、在百度搜索问题的答案、在打车软件搜索附近的车。 ELK技术栈 elasticsearch结合kibana、Logstash、Beats,也就是elastic stack(ELK)。被广泛应

    2024年01月17日
    浏览(39)
  • Elasticsearch分布式搜索

    目录 实用篇-ES-环境搭建 1. 什么是elasticsearch ​2. 倒排索引 3. elasticsearch对比mysql ​4. 安装elasticsearch 5. 安装kibana 6. 安装IK分词器 7. IK分词器的词典扩展和停用 实用篇-ES-DSL操作文档 1. mapping属性 2. 创建索引库 3. 查询、修改、删除索引库 4. 新增、查询、删除文档 5. 修改文档 实

    2024年04月22日
    浏览(49)
  • 分布式搜索--elasticsearch

    一、初识 elasticsearch  1. 了解 ES ① elasticsearch 是一款非常强大的开源   搜索引擎 ,可以帮助我们从海量数据中   快速找到需要的内容 ② elasticsearch 结合 kibana、Logstash、   Beats,也就是 elastic stack (ELK),被   广泛应用在日志数据分析、实时监控等   领域 ③ elasticsearch 是e

    2024年02月12日
    浏览(60)
  • 分布式搜索elasticsearch概念

    什么是elasticsearch? elasticsearch是一款非常强大的开源搜索引擎,可以帮助我们从海量数据中快速找到需要的内容   目录 elasticsearch的场景 elasticsearch的发展  Lucene篇 Elasticsearch篇   elasticsearch的安装 elasticsearch的场景 elasticsearch结合kibana、Logstash、Beats,也就是elastic stack (ELK)。被

    2024年02月04日
    浏览(40)
  • 【Springcloud】分布式搜索elasticsearch

    先看下翻译: elasticsearch是一款非常强大的 开源搜索引擎 ,可以帮助我们 从海量数据中快速找到需要的内容 以下是生活中ES的使用场景: 项目在运行的时候会产生海量的日志信息,而elasticsearch结合kibana、Logstash、Beats,也就是elastic stack( ELK ),即ELK技术栈。被广泛应用在

    2024年02月08日
    浏览(41)
  • 【分布式搜索引擎elasticsearch】

    什么是elasticsearch? 一个开源的分布式搜索引擎,可以用来实现搜索、日志统计、分析、系统监控等功能 什么是elastic stack(ELK)? 是以elasticsearch为核心的技术栈,包括beats、Logstash、kibana、elasticsearch elasticsearch结合kibana、Logstash、Beats,也就是elastic stack(ELK)。被广泛应用在

    2024年02月10日
    浏览(49)
  • 分布式搜索引擎----elasticsearch

    目录 1、初识elasticsearch 1.1、什么是elasticsearch 1.2.ELK技术栈 2、正向索引和倒排索引 2.1、正向索引 2.2、倒排索引 2.3、正向索引和倒排索引的区别 3、elasticsearch中的概念理解 3.1、文档和字段 3.2、索引和映射 3.3、mysql与elasticsearch         elasticsearch是一款非常强大的开源搜索

    2024年02月11日
    浏览(52)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包