数据可靠存储 单点故障  分库
冷备 热备  主从备份 副本 
代理 分发SQL语句 汇总结果
高可用 master 选举
分片 shard 

数据和索引分离 数据压缩 

Elasticsearch Lucene
RESTful API
集群节点发现 多播(multicast)   单播

核心概念

Cluster 集群   
Node 节点
Shard 分片
Replia 副本
全文检索

与数据库对比

数据库 表 行 列
Databases -> Tables -> Rows -> Columns
schema 
SQL 
B+树索引
 
索引 类型 文档 字段
Indices -> Types -> Documents -> Fields
mapping 
query DSL
倒排索引 基于 Lucene


实时分布式搜索引擎
索引分拆成多个分片，每个分片可有零个或多个副本。集群中的每个数据节点都可承载一个或多个分片，并且协调和处理各种操作； 
自动负载均衡和路由
插件机制，分词插件、同步插件、Hadoop插件、可视化插件等

es的性能测试工具 esrally

ES使用场景
2013年初，GitHub抛弃了Solr，采取ElasticSearch 来做PB级的搜索。
维基百科：启动以elasticsearch为基础的核心搜索架构。 
新浪32亿条实时日志分析处理
挖财日志采集和分析体系
有赞业务日志处理
站内搜索

./bin/elasticsearch 
./bin/elasticsearch -d 
-d 后台运行
ElasticStack（Elasticsearch、Logstash、Kibana、Beat）
ELK 

每一个索引由一个或多个分片组成。每个分片是Luncene索引的一个实例
数据写入分片时，定时生成 不可变的Lucene段 segment
随着分段数（segment）的增长，定期地合并成较大的segments。
内存bugffer + translog   定时flush 生成  segment


flush merge  磁盘I/O

分片是ES在集群分发数据的单位。 在重新平衡数据时 （例如 发生故障后） 移动分片的速度 取决于分片的大小和数量以及网络和磁盘性能。

避免分片过大 ， 分片大小为50GB通常被界定为适用于各种用例的限制。

删除文档 只做标记 删除的文档将继续占据磁盘空间和一些系统资源，直到被合并

尽可能使用基于时间的索引来管理数据。根据保留期（retention period，可以理解成有效期）将数据分组。
基于时间的索引还可以轻松地随时间改变主分片和副本分片的数量

查询在每个分片的单个线程中执行 可以并行处理多个分片 可以在相同分片上执行多个查询和聚合。

索引创建后 分片数不可修改 副本数可修改
如果不创建副本，当主分片发生问题时，可能会丢失数据的丢失。

理想的分片数量依赖于节点的数量
节点数 = 分片数 *（副本数+1）




索引存储方式 基于文件系统的存储
elasticsearch.yml 指定存储类型
index.store.type: niofs

Simple FS（简单文件系统） Lucene SimpleFsDirectory    并发性能较差
NIO FS（NIO文件系统）    Lucene NIOFSDirectory
MMap FS（内存映射文件系统）Lucene MMapDirectory  映射文件到内存中（MMAP）需要足够的虚拟地址空间

Linux下虚拟内存设置：
sysctl -w vm.max_map_count=262144
永久生效
echo "vm.max_map_count=262144" >> /etc/sysctl.conf 
sysctl -p

-a   显示所有的系统参数
-p   从指定的文件加载系统参数，不指定从/etc/sysctl.conf中加载



段合并
段太多的影响
消耗资源：每一个段都会消耗文件句柄、内存和cpu运行周期； 
查询变慢：每个查询请求都必须轮流检查每个段；段越多，搜索越慢。
后台进行段合并 
段合并时会将已删除文档从文件系统中清除。 

段合并的作用
减少资源（尤其是文件句柄）消耗
删除标记为删除的文档，释放资源
提升查询效率

段合并 磁盘IO  影响性能

副本与集群备份
使用 snapshot API备份集群。 
完整备份 快照
增量备份

优化
机械硬盘和固态硬盘
数据结构优化
查询优化 避免wildcard模糊匹配很长的字符串

CPU飙升排查
GET /_nodes/hot_threads?pretty

集群扩展
垂直扩展   加内存 磁盘等
水平扩展  加节点 增加分片 副本 

集群架构设计考虑因素

节点数量  索引 每个索引的分片数
能接受的出现故障的节点数
性能 冗余 高可用

大规模集群节点角色


路由节点或查询聚合节点
发送子查询到其他节点，收集和合并结果，以及响应发出查询的客户端。
node.master: false
node.data: false

数据节点
node.master: false
node.data: true

候选主节点
node.master: true
node.data: false
http.enabled: false

候选主节点禁用Http协议 ，避免意外地在这些节点上进行查询。
候选主节点相比于数据节点和路由节点可以使用更少的资源，确保仅仅被用来处理和主节点相关的工作。


高负载场景优化建议

1）选择正确的存储 ,选择默认的default存储类型。
2）按需设定刷新频率 
索引刷新频率：文档需要多长时间才能出现在搜索结果中。 
刷新频率越短，查询越慢，且索引文档的吞吐率越低。 
默认刷新频率：1s刷新一次。 
无限的增加刷新时间是没有意义的，因为超过一定的值（取决于你的数据负载和数据量）之后，性能提升变得微乎其微。
3）线程池优化 
4）调整合并过程 
index.merge.policy.mery_factory默认值10，
调低会导致更少的段，更低的RAM消耗，更快的查询速度和更慢的索引速度； 
调高，导致索引由更多的分段组成，更高的RAM消耗，更慢的查询速度和更快的索引速度。
5）合理数据分布 
把索引分散到多个分片上来降低服务器CPU和I/O子系统的压力。

如果节点无法处理查询带来的负载，可以增加更多的ES节点，并增加副本的数量，于是主分片的物理拷贝会部署到新增节点上。
文档索引会慢一些，但是会提升查询处理能力。

高负载、高查询频率场景

1）启动过滤器缓存和分片查询缓存 
过滤器缓存配置：indices.cache.filter.size 
分片查询缓存配置：indices.cache.query.enable

2）优化查询语句结构 
3）使用路由 
有着相同路由值的数据都会保存到相同的分片上。
4）并行查询 
建议数据平均分配，多个节点可以有相同的负载。
5）字段数据缓存 
当使用聚合和排序等字段数据缓存相关操作时，遇到了内存相关的问题（内存泄漏或者GC停顿），可以考虑使用 doc value。
6）控制size和shard_size 
主要针对聚合操作。 
增加size和shard_size能使得聚合结果更准确，代价是：更多的网络开销和内存使用； 
减少size和shard_size能使得聚合不那么精确，代价是：网络开销小和内存使用率低。

高负载、高索引吞吐量场景
1）批量索引 批量索引代替逐个索引文档。
2）doc values和索引速度的取舍 
如果只关心更高的索引速度和更大的索引吞吐量，可以考虑不使用doc values。 
如果有大量的数据，为了使用聚合和排序功能而不产生内存相关问题，使用 doc values。

3）控制文档字段 
方式一：_source 控制字段输出； 
方式二：禁用_all。 减少文档的大小和其内文本字段的数量会让索引稍快一些。

4）索引的结构和副本 
主分片部署到所有的节点上，以便并行的索引文档，加快索引的速度。 
过多的副本导致索引速度下降。
5）调整预写日志。
6）存储优化 
使用SSD——原因：速度优势明显； 

7）索引期间的内存缓存 
建议给每个索引期间生效的分片分配512MB内存。 
indices.memeory.index_buffer_size是设置节点的，而不是分片。