Elasticsearch核心知识篇(12)
node是一个ES实例(非服务器)，shard是一个服务(就是一个lucene服务，在一台电脑上可以实例多个lucene服务)，master就是一个特殊的node
图解横向扩容过程，如何超出扩容极限，以及如何提升容错性
-
primary&replica自动负载均衡，6个shard，3 primary，3 replica
- 尽量保证每个node上的shard的数量是一致的，负载均衡
-
每个node有更少的shard，IO/CPU/Memory资源给每个shard分配更多，每个shard性能更好(
重点) -
扩容的极限，6个shard（3 primary，3 replica），最多扩容到6台机器，每个shard可以占用单台服务器的所有资源，性能最好
-
超出扩容极限，动态修改replica数量，9个shard（3primary，6 replica），扩容到9台机器，比3台机器时，拥有3倍的读吞吐量
-
3台机器下，9个shard（3 primary，6 replica），资源更少，但是容错性更好，最多容纳2台机器宕机，6个shard只能容纳1台机器宕机
-
这里的这些知识点，你综合起来看，就是说，一方面告诉你扩容的原理，怎么扩容，怎么提升系统整体吞吐量；另一方面要考虑到系统的容错性，怎么保证提高容错性，让尽可能多的服务器宕机，保证数据不丢失
下面的图片中有一个错误：6个shard,3台服务器，容错性是什么？最多容忍几台服务器宕机，保证数据不丢失
一台
- 扩容过程分析
理解：
- 假设原来有两个node(电脑)，一共有6个节点，node_one上p0,p1,02,node_two上R0,R1,R2,现在新增一个节点(node_three),这个时候cluster,会自动将这个节点纳入麾下，这样自动进行负载均衡，node_one上p0,p1，node_two上R0,R2，node_three上P2,R1，完成分配。
- 容错纠正
Elasticsearch核心知识篇(13)
图解Elasticsearch容错机制：master选举，replica容错，数据恢复
- 9 shard，3 node
- master(其实就是一个node) node宕机，自动master选举，短时间red
- replica容错：新master将replica提升为primary shard，yellow
- 重启宕机node，master copy replica到该node，使用原有的shard并同步宕机后的修改，green
Elasticsearch核心知识篇(14)
{
"_index": "test_index",
"_type": "test_type",
"_id": "1",
"_version": 1,
"found": true,
"_source": {
"test_content": "test test"
}
}
_index元数据
- 代表一个document存放在哪个index中
- 类似的数据放在一个索引，非类似的数据放不同索引：product index（包含了所有的商品），sales index（包含了所有的商品销售数据），inventory index（包含了所有库存相关的数据）。如果你把比如product，sales，human resource（employee），全都放在一个大的index里面，比如说company index，不合适的。
- index中包含了很多类似的document：类似是什么意思，其实指的就是说，这些document的fields很大一部分是相同的，你说你放了3个document，每个document的fields都完全不一样，这就不是类似了，就不太适合放到一个index里面去了。
- 索引名称必须是小写的，不能用下划线开头，不能包含逗号：product，website，blog
_type元数据
- 代表document属于index中的哪个类别（type）
- 一个索引通常会划分为多个type，逻辑上对index中有些许不同的几类数据进行分类：因为一批相同的数据，可能有很多相同的fields，但是还是可能会有一些轻微的不同，可能会有少数fields是不一样的，举个例子，就比如说，商品，可能划分为电子商品，生鲜商品，日化商品，等等。
- type名称可以是大写或者小写，但是同时不能用下划线开头，不能包含逗号
_id元数据
- 代表document的唯一标识，与index和type一起，可以唯一标识和定位一个document
- 我们可以手动指定document的id（put /index/type/id），也可以不指定，由es自动为我们创建一个id
