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://www.bubuko.com/infodetail-2605974.html