ElasticSearch：小结

1、分片：支持水平扩展；可以分布式的并发的查询，增加查询效率。
2、副本：每个分片都有自己的副本，保证容错性；扩展吞吐量，因为搜索可以在所有的副本上进行；分片的分配都是由Master来的。
3、倒排索引：给每个字段都都建立了一个倒排索引，字段和主键_id的关联关系，如果需要分词的字段则分词后每个词都做一个关联。查询的时候就根据value找key(_id)。
4、主键（_id）的hash值和主分片取余得到哪个分片；分片控制-用户可以访问分片的任意副本都能获取到数据，一般都是做轮询。所以一旦分片数量设定后就不能更改，否则就会查不到数据。
5、写数据流程：
1）先请求到协调节点上，协调节点对数据做了路由后再把请求发到对应的节点上（主分片所在的节点）。
2）主分片储存完之后会把请求发到副本分片上，主分片和副本分片写完了才返回给客户端成功。
3）可以设置只写主分片成功就返回，也可以设置所有的副本分片都写成功才返回，也可以设置大部分副本分片写完就返回。
6、存储流程：
1）先写到momery buffer中，同时写入内存中的translog中；写到momery buffer是为了写的快。
2）每次index、bluk、delete、update操作后都会将translog刷新到磁盘上，就是每次都嗲用fsync()函数，刷新成功后才会返回客户端成功。
3）默认每隔1s会把momery buffer中的数据refresh到 File System Cache 中，此时数据就可以被查询到，也就是说es的实时性在1s内；同样的也可以每次插入后手动调用/_refresh接口或者也可以增大这个refresh间隔时间以增大性能。
4）动态更新索引：每次refresh操作都会生成一个segment file，后台有线程做segment的合并。
5）默认每隔30min或者translog文件达到一定大小时，会主动进行一次flus操作，把 File System Cache 中的数据落盘，也就是调用操作系统的fsync()函数；然后会删除translog中的内容。
6）translog的存在就是为了防止refresh到文件缓存中突然宕机，还可以从translog中恢复数据。
7、读数据流程：
GET某条数据的时候还是先找协调节点，协调节点计算数据所在的主分片和副本分片，每次都是做负载均衡轮询查某一个分片
8、检索数据流程：
1）还是找协调节点，协调节点将请求分到到所有的分片（主分片或副本分片都可以）；
2）每个分片查到的结果返回给协调节点（其实就是_id），协调节点根据_id路由到对应的分片节点上查找数据。
9、Es的优化
1）磁盘最好是SSD；
2）内存设置不超过物理内存的50%，因为es会借助操作系统的缓存，会占用操作系统的内存，最好别超过32G。
3）合理设置分片策略：
分片设置的过多：每个分片都可以看作一个搜索引擎会占用资源，那么在同一个节点上查询多个分片的时候会竞争资源
分片设置的过少：
一般设置分片数量不超过节点数的3倍！！！
4）对于新节点的加入和现有节点的离线，es都会自动的在可用节点间进行分片的再均衡，此时服务器压力会变大。
所以对于节点瞬时的中断，可以推迟它再均衡的时间，默认是会等待1分钟。
可以全局设置也可以设置某个索引库（“index.unassigned.node_left.delayed_timeout”: “10m”）。
5）查询的时候带上路由
6）如果对实时性要求不高，可以把refresh间隔，比如30s，这样生成segment就会变少，对内存消耗变少，增加性能。
8）增大flush设置。
7）减少副本的数量，副本数越多写的效率越慢；大批量的导入操作时可以先把副本数量变为0。