ELK系列二:Elasticsearch的架构原理和配置优化 - 土拨鼠不再挖洞
2018-10-23 18:57:0 Author: www.cnblogs.com(查看原文) 阅读量:5 收藏

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,)


文章来源: https://www.cnblogs.com/KevinGeorge/p/9838531.html
如有侵权请联系:admin#unsafe.sh