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,分布式系统并行生成时不可能会发生冲突