一、Elasticsearch的数据组织架构
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中的某个字段值。 <strong>从索引到后面都是组织数据的结构概念，分片（不管主副）能够自由分布在集群中的不一样结点上，也不关系结点的主副概念（master-cluster和slave-cluster）。</strong>
1.二、建立索引时，如何分配主从分片等的配置
<strong>通常使用elasticsearch-head建立分片时，默认分片数五、副本数1（意思是每一个分片一个副本），分片数建立后不可修改，副本数可修改，数量按须要配置。注意：一个shared的主分片和副本不能放在同一个结点上，不然结点故障的容错机制（数据冗余备份）将失去效果。</strong> 
node
1.三、分片的路由计算
<strong>公式以下：</strong>数据库
shared = hash(_id) %number_of_primary_shareds
通常状况下是对_id字段进行hash处理后对主分片数目求余获得该条数据具体应该写入那个分片。缓存
1.四、主副分片保障数据一致性
<strong>默认状况下，数据写入主分片后，会给全部副本发送方消息，当有一个副本也成功写入数据后，及返回数据写入成功。如须要修改能够以下修改配置</strong>网络
?consistency=all
1.五、分片的分配
通常是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.六、自动发现配置
- 组播方式 223.2.2.4 54328 发送clustername信息
- 单播方式
1.七、其余配置项
?timeout=30s #默认60s，含义是Elasticsearch等待异常结点是否能够恢复的等待时间。
二、Elasticsearch的数据写入和检索以及数据防丢失机制
2.一、数据写入流程
<strong> 内存buffer->segment->磁盘 </strong> segment能够理解为一个倒排索引的子集，举例以下：并发
doc1:"tom","jill" doc2:"tom"
倒排索引以下表负载均衡
| 字段/文档 | doc1 | doc2 |
|---|---|---|
| tom | x | x |
| jill | x |
2.二、segment的机制
- 写盘机制：一个segment刷到缓存中，Lucene能够去检索，等到segment真的写到磁盘去了，commit文件更新，commit能够理解为segment的目录表，刷新（refresh）时间默认是1s，基本属于准实时检索。
- 归并机制：segment太多，不利于系统和性能，会归并。
2.三、写盘和归并的配置
#修改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.四、translog磁盘同步
磁盘写入等待缓存一块儿写，记录数据信息，若是出现异常，会按照这个文件恢复数据，可是这个数据5s写一次，因此仍是有可能丢失5s的数据。若是须要，能够调小这个时间间隔：curl
index.gateway.local.sync
默认30分钟、或者满512M才会清空。（或者确实写入磁盘，commit文件确认了，translog才会清空flush，）elasticsearch