Elasticseach的横向扩展、容错机制(3)

1、横向扩容过程,如何超出扩容极限,以及如何提升容错性

(1)primary&replica自动负载均衡,6个shard,3 primary,3 replica

(2)每个node有更少的shard,IO/CPU/Memory资源给每个shard分配更多,每个shard性能更好

(3)扩容的极限,6个shard(3 primary,3 replica),最多扩容到6台机器,每个shard可以占用单台服务器的所有资源,性能最好

(4)超出扩容极限,动态修改replica数量,9个shard(3primary,6 replica),扩容到9台机器,比3台机器时,拥有3倍的读吞吐量

(5)3台机器下,9个shard(3 primary,6 replica),资源更少,但是容错性更好,最多容纳2台机器宕机,6个shard只能容纳0台机器宕机

(6)这里的这些知识点,你综合起来看,就是说,一方面告诉你扩容的原理,怎么扩容,怎么提升系统整体吞吐量;另一方面要考虑到系统的容错性,怎么保证提高容错性,让尽可能多的服务器宕机,保证数据不丢失

1、Elasticsearch容错机制:master选举,replica容错,数据恢复

(1)9 shard,3 node

(2)master node宕机,自动master选举,red

(3)replica容错:新master将replica提升为primary shard,yellow

(4)重启宕机node,master copy replica到该node,使用原有的shard并同步宕机后的修改,green

############################################################################################################

PUT /test_index/test_type/1

{

"test_count":"test test"

}

1、_index元数据

2、_type元数据

3、_id元数据

{

"_index": "test_index",

"_type": "test_type",

"_id": "1",

"_version": 1,

"found": true,

"_source": {

"test_content": "test test"

}

}

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

1、_index元数据

(1)代表一个document存放在哪个index中

(2)类似的数据放在一个索引,非类似的数据放不同索引:product index(包含了所有的商品),sales index(包含了所有的商品销售数据),inventory index(包含了所有库存相关的数据)。如果你把比如product,sales,human resource(employee),全都放在一个大的index里面,比如说company index,不合适的。

(3)index中包含了很多类似的document:类似是什么意思,其实指的就是说,这些document的fields很大一部分是相同的,你说你放了3个document,每个document的fields都完全不一样,这就不是类似了,就不太适合放到一个index里面去了。

(4)索引名称必须是小写的,不能用下划线开头,不能包含逗号:product,website,blog

2、_type元数据

(1)代表document属于index中的哪个类别(type)

(2)一个索引通常会划分为多个type,逻辑上对index中有些许不同的几类数据进行分类:因为一批相同的数据,可能有很多相同的fields,但是还是可能会有一些轻微的不同,可能会有少数fields是不一样的,举个例子,就比如说,商品,可能划分为电子商品,生鲜商品,日化商品,等等。

(3)type名称可以是大写或者小写,但是同时不能用下划线开头,不能包含逗号

3、_id元数据

(1)代表document的唯一标识,与index和type一起,可以唯一标识和定位一个document

(2)我们可以手动指定document的id(put /index/type/id),也可以不指定,由es自动为我们创建一个id

############################################################################################################

1、手动指定document id

(1)根据应用情况来说,是否满足手动指定document id的前提:

一般来说,是从某些其他的系统中,导入一些数据到es时,会采取这种方式,就是使用系统中已有数据的唯一标识,作为es中document的id。举个例子,比如说,我们现在在开发一个电商网站,做搜索功能,或者是OA系统,做员工检索功能。这个时候,数据首先会在网站系统或者IT系统内部的数据库中,会先有一份,此时就肯定会有一个数据库的primary key(自增长,UUID,或者是业务编号)。如果将数据导入到es中,此时就比较适合采用数据在数据库中已有的primary key。

如果说,我们是在做一个系统,这个系统主要的数据存储就是es一种,也就是说,数据产生出来以后,可能就没有id,直接就放es一个存储,那么这个时候,可能就不太适合说手动指定document id的形式了,因为你也不知道id应该是什么,此时可以采取下面要讲解的让es自动生成id的方式。

(2)put /index/type/id

PUT /test_index/test_type/2

{

"test_content": "my test"

}

2、自动生成document id

(1)post /index/type

POST /test_index/test_type

{

"test_content": "my test"

}

{

"_index": "test_index",

"_type": "test_type",

"_id": "AVp4RN0bhjxldOOnBxaE",

"_version": 1,

"result": "created",

"_shards": {

"total": 2,

"successful": 1,

"failed": 0

},

"created": true

}

(2)自动生成的id,长度为20个字符,URL安全,base64编码,GUID,分布式系统并行生成时不可能会发生冲突

原文地址:http://blog.51cto.com/395469372/2117771

时间: 2024-11-02 18:02:14

Elasticseach的横向扩展、容错机制(3)的相关文章

Elasticsearch 横向扩容以及容错机制

写在前面的话:读书破万卷,编码如有神-------------------------------------------------------------------- 参考内容: <Elasticsearch顶尖高手系列-快速入门篇>,中华石杉 -------------------------------------------------------------------- 主要内容包括: 横向扩容 容错机制 ------------------------------------

presto的动态化应用(一):presto节点的横向扩展与伸缩

一.presto动态化概述 近年来,基于hadoop的sql框架层出不穷,presto也是其中的一员.从2012年发展至今,依然保持年轻的活力(版本迭代依然很快),presto的相关介绍,我们就不赘述了,相信看官多对presto有或多或少的了解,详细的一些说明可以看官网(https://prestodb.io)的说明. presto自身功能和思想富有先进性,虽然由于是内存计算,稳定性方面还有很大提升空间,但整体依然在adhoc方面有很好的竞争力,我们本次介绍针对我们团队对于presto部分应用个

Flink状态管理和容错机制介绍

本文主要内容如下: 有状态的流数据处理: Flink中的状态接口: 状态管理和容错机制实现: 阿里相关工作介绍: 一.有状态的流数据处理# 1.1.什么是有状态的计算# 计算任务的结果不仅仅依赖于输入,还依赖于它的当前状态,其实大多数的计算都是有状态的计算. 比如wordcount,给一些word,其计算它的count,这是一个很常见的业务场景.count做为输出,在计算的过程中要不断的把输入累加到count上去,那么count就是一个state. 1.2.传统的流计算系统缺少对于程序状态的有效

ack是什么,如何使用Ack机制,如何关闭Ack机制,基本实现,STORM的消息容错机制,Ack机制

1.ack是什么 ack 机制是storm整个技术体系中非常闪亮的一个创新点. 通过Ack机制,spout发送出去的每一条消息,都可以确定是被成功处理或失败处理, 从而可以让开发者采取动作.比如在Meta中,成功被处理,即可更新偏移量,当失败时,重复发送数据. 因此,通过Ack机制,很容易做到保证所有数据均被处理,一条都不漏. 另外需要注意的,当spout触发fail动作时,不会自动重发失败的tuple,需要spout自己重新获取数据,手动重新再发送一次 ack机制即, spout发送的每一条消

RDD之七:Spark容错机制

引入 一般来说,分布式数据集的容错性有两种方式:数据检查点和记录数据的更新. 面向大规模数据分析,数据检查点操作成本很高,需要通过数据中心的网络连接在机器之间复制庞大的数据集,而网络带宽往往比内存带宽低得多,同时还需要消耗更多的存储资源. 因此,Spark选择记录更新的方式.但是,如果更新粒度太细太多,那么记录更新成本也不低.因此,RDD只支持粗粒度转换,即只记录单个块上执行的单个操作,然后将创建RDD的一系列变换序列(每个RDD都包含了他是如何由其他RDD变换过来的以及如何重建某一块数据的信息

架构师之路--搜索业务和技术介绍及容错机制

今天和搜索部门一起做了一下MQ的迁移,顺便交流一下业务和技术.发现现在90后小伙都挺不错.我是指能力和探究心.我家男孩,不招女婿. 在前面的文章中也提到,我们有媒资库(乐视视频音频本身内容)和全网作品库(外部视频音频内容),数据量级都在千万级.我们UV,PV,CV,VV都是保密的.所以作为一个合格的员工来说………………数值我也不知道.总之,这些数据作为最终数据源,要走一个跨多个部门的工作流才最终出现在用户点击搜索按钮出现的搜索框里.大体流程图如下: 这个流程图之所以没像以往一样手绘,嗯,那是因为

WinSrv2016横向扩展存储(SDS)[无共享存储]

在Windows Server 2016中引入了一个新存储功能,这个功能非常类似其他的横向扩展存储解决方案,如VMware的VSAN,可以进行存储空间的直连,使用的是存储节点的本地存储,也就是使用每一个存储节点的内部磁盘设备构建HA存储系统连接到单个的存储节点: 所有的节点是利用SMB3来直接与存储空间进行通信: 存储空间无缝集成组成Windows Server的软件定义存储功能,包括横向扩展的文件服务器,群集共享卷,存储空间和故障转移群集. 除此之外按照同样的道理也可以提供给Hyper-V虚拟

构建横向扩展文件服务器

上一篇中,主要演示了如何构建高可用SMB3.0wenjian 服务器,今天主要为大家演示如何构建横向扩展文件服务器并将Hyper-V虚拟机创建到该服务器中. 在 Windows Server 2012 中,横向扩展文件服务器设计用于提供横向扩展文件共享,该类共享可供基于文件的服务器应用程序存储连续使用.横向扩展文件共享允许从同一群集的多个节点上共享同一文件夹.例如,对于使用在 Windows Server 2012 中引入的服务器消息块 (SMB) 扩展的四节点文件服务器群集,运行 Window

Puppet扩展篇6-通过横向扩展puppetmaster增加架构的灵活性

零基础学习Puppet自动化配置管理系列文档 puppetmaster横向扩展将采用以下架构进行部署,也可以参考<puppet实战>第246页的内容. puppet集群扩展架构图 主机IP地址信息机用途表 puppet集群扩展架构图 工作原理: 客户端通过配置ca_server指定CA服务器,以达到独立CA服务器的目的. CA服务器可以部署在多个机房. Master集群可以在同一机房配置负载均衡器,也可以使用DNS解析Puppet Master域名到不同机房的多台服务器,通过DNS实现负载均衡