1、Elasticsearch的数据组织架构

---

---

1.1、Elasticsearch结构概念

---

• 集群（cluster）：拥有相同cluster-name的elasticsearch结点的集合（每个结点其实就是一个elasticsearch进程实例）。
• 节点（node）：集群中的一个 Elasticearch 实例。
• 索引（index）：相当于关系型数据库中database的概念，比如2018.01.01日志的IDS日志单独形成一个索引，IDS-2018.01.01，这是一个逻辑的概念。
• 分片（shared）：
  • 主分片（primary shared）：索引的子集，索引可以切分成多个分片，分布到不同的集群节点上。
  • 副本（replica shared）：一个主分片可以有一个或多个副本分片作为备份。
• 类型（type），相当于关系型数据库中table的概念。比如IDS-2018.01.01中的warnning.log
• 文档（document），相当于一条数据的原始数据的集合，一般就是一条JSON。
• 字段（field），JSON中的某个字段值。
  从索引到后面都是组织数据的结构概念，分片（无论主副）可以自由分布在集群中的不同结点上，也不关系结点的主副概念（master-cluster和slave-cluster）。

1.2、创建索引时，如何分配主从分片等的配置

---

一般使用elasticsearch-head创建分片时，默认分片数5、副本数1（意思是每个分片一个副本），分片数创建后不可修改，副本数可修改，数量按需要配置。注意：一个shared的主分片和副本不能放在同一个结点上，否则结点故障的容错机制（数据冗余备份）将失去效果。

1.3、分片的路由计算

---

公式如下：

shared = hash(_id) %number_of_primary_shareds

一般情况下是对_id字段进行hash处理后对主分片数目求余得到该条数据具体应该写入那个分片。

1.4、主副分片保障数据一致性

---

默认情况下，数据写入主分片后，会给所有副本发送方消息，当有一个副本也成功写入数据后，及返回数据写入成功。如需要修改可以如下修改配置

?consistency=all

1.5、分片的分配

---

一般是Elasticsearch自动进行，一些参数可以控制该过程的

cluster.routing.allocation.enable #可以分配那些分片，默认是all，none是彻底拒绝，其他选项有primaries和new_primaries。
cluster.routing.allocation.allow_rebalance #默认是indices_all_active，就是等待所有分片启动后，开始负载均衡，不然启动过程中浪费太多流量。
cluster.routing.allocation.cluster_concurrent_rebalance #默认是两个，含义是并发负载均衡任务数量，当结点数目增加，且负载压力不大的条件下，可适当增加。
cluster.routing.allocation.node_initial_primaries_recoveries #结点重启时，允许同时恢复的主分片数，默认是4个，如果结点是多磁盘，且I/O压力不大时，可以适当增加。
cluster.routing.allocation.node_concurrent_recoveries #除主分片重启恢复意外的情况下，可以同时运行的数据恢复业务，默认是2个。
indices.recovery.concurrent_stream #网络复制恢复分片时候的流数，默认是3个。
indices.recovery.max_bytes_per_sec #结点恢复时候的速率，默认40MB，建议加大。

1.6、自动发现配置

---

• 组播方式 223.2.2.4 54328 发送clustername信息
• 单播方式

1.7、其他配置项

---

?timeout=30s #默认60s，含义是Elasticsearch等待异常结点是否可以恢复的等待时间。

2、Elasticsearch的数据写入和检索以及数据防丢失机制

---

---

2.1、数据写入流程

---

内存buffer->segment->磁盘
segment可以理解为一个倒排索引的子集，举例如下：

doc1:"tom","jill"
doc2:"tom"

倒排索引如下表

字段/文档	doc1	doc2
tom	x	x
jill	x

2.2、segment的机制

---

• 写盘机制：一个segment刷到缓存中，Lucene可以去检索，等到segment真的写到磁盘去了，commit文件更新，commit可以理解为segment的目录表，刷新（refresh）时间默认是1s，基本属于准实时检索。
• 归并机制：segment太多，不利于系统和性能，会归并。

2.3、写盘和归并的配置

---

#修改refresh时间 ，设置成-1，则停止refresh
curl -XPOST http://127.0.0.1:9200/IDS-2018.01.01/_settings -d '{"refreah_interval":"10s"}' 
#修改归并配置
curl -XPOST http://127.0.0.1:9200/IDS-2018.01.01/_settings -d '{"persistent":{"key-name":"value"}}' 
#归并配置选项
indices.store.throttle.max_bytes_per_sec #归并线程限速配置，默认20M，建议迁移到100M或更高。
index.merge.policy.floor_segment #默认2M，小于这个大小的segment，优先归并。
index.merge.policy.max_merge_at_once #默认一次最多归并10个segment。
index.merge.policy.max_merge_at_once_explicit #默认optimize时候，一次最多归并20个segment。
index.merge.policy.max_merge_segment #默认5GB。归并后的segment的大最大大小。

2.4、translog磁盘同步

磁盘写入等待缓存一起写，记录数据信息，如果出现异常，会按照这个文件恢复数据，但是这个数据5s写一次，所以还是有可能丢失5s的数据。如果需要，可以调小这个时间间隔：

index.gateway.local.sync

默认30分钟、或者满512M才会清空。（或者确实写入磁盘，commit文件确认了，translog才会清空flush，）