http://nginxs.blog.51cto.com/
http://nginxs.blog.51cto.com/从2014年到现在接触ES（Elasticsearch）已经两年多了，感触良多尤其ES的开盒即用特性完全区别于之前接触复杂的hadoop和solor。ES不需要你对它了解就能很快入门，而且ES的实时搜索，自动拓展，自愈功能深深吸引我。最近很多朋友也开始使用向我问了很多常见问题，我在这总结了一些使用中踩过的坑希望大家对ES有更多的了解。
简介
Elasticsearch是基于Lucene开发的一个准实时搜索服务，搜索延时在秒级。ES存储主要通过自身解析json数据，然后json里面的key映射为Lucene里面的字段，使用lucene进行搜索和索引。ES不仅支持普通的全文搜索和按词搜索，还支持模糊匹配，近义词搜索，聚合，排序，geo等特性。ES的开源特性也使得它社区活跃，版本迭代更新迅速，现在主要分为2.0和5.0两个大版本，建议大家使用最新的5.0版本会更容易升级和获取一些更高级的特性。
下面是一些上线或者线上使用Elasticsearch需要了解的特性
CPU
es主要依赖于硬盘和内存，所以对CPU要求不高，一般8核就行，如果并发比较多可以适当增加。
硬盘
硬盘决定你es写入读取数据速度，磁盘建议用15k的机械硬盘,并配置为raid0，如果集群节点<5个，请使用raid5，这样保证一个硬盘故障不会影响服务。虽然es本身可以通过分片去保证数据的冗余，但是es每个节点大量数据爬行还是对较小的集群有一定影响。（土豪直接上SSD，需要正确配置I/O调度程序，阵列卡建议>h710，否则就像ssd跑车上安装一个拖拉机引擎）
内存优化
1. ES的内存使用分为两部分ES缓存和Lucene通过内核缓存加速一些数据。
2 . 如果服务器内存 `nG > 64G`,ES的内存尽量设置低于32G，建议最大31G. 因为es使用“内存指针压缩”技术，一旦内存内存大于32G这项技术将失效，内存有效使用只有原来的60%~70%。你不必为内存浪费而担心，因为lucene会通过系统把一些聚合和排序的数据缓存起来方便你快速查询使用。
3 .如果服务器内存 `nG < 64G`，建议给ES分配 内存 (n-2)/2G. 首先2G是给系统预留，然后es和lucene
4 . 如果你想继续你的实时查询，尽量不要使用swap(交换分区)，建议关闭系统swap使用
网络
- 建议千兆光纤，高速网络可以保证集群节点故障后快速恢复，以及添加节点后快速再平衡。
- 尽量不要跨机房，除非需要灾备，或者有足够的带宽，否则你将迎来es节点数据同步的无限等待。
数据文档结构数据
因为所有es节点需要实时同步‘索引列表’，‘文档类型’，‘字段名’等信息，所以在节点数固定的情况下索引，字段名等不要太多否则会给es的master节点造成压力。
简单举例：我要保存用户提交字段和信息，各个字段名因为是动态生成，理论上是无上限的，但是es的master要实时的同步这些字段信息到每个节点，如果现在只有100个字段还好，要是有1000个字段就会产生问题，如果有2000个字段就严重到无法使用了，当然索引的数量也是同样的意义，
索引优化
es的每个索引默认总计10个分片，5个主分片，每个主分片对应一个副分片。
1 . 当然很多情况下这个无法满足你实际需求，例如你的集群有8个节点，计划单个索引超过100亿条数据，为了让这个索引查询速度快一点，你可以增加索引分片数量：1.增加主副分片对数，增加副分片的数量。这样不仅加速搜索还增加了数据的冗余。
2 . 一些只读的索引可以使用‘optimize的API’进行把每个索引合并为一个单独数据段，这样可以节省资源加速操作，但是需要注意这样会消耗一定IO，如果当前节点请求繁忙，不要进行此类操作。
3 . 在使用索引的时候尽量使用索引别名，在以后索引重建或者索引名变更时避免宕机维护。
操作优化
1. 并发请求不要一次太多，否则超过es内部队列长度将失败。
2. 如果一次一定要提交太多任务写入尽量添加失败判断，一旦失败等待3~5秒重试操作，否则数据将丢失。
3.文档尽量一次写入不要更改和删除，因为es的更改和删除只是给旧数据做了一个标签，查询的时候依然会查询匹配，只是不在结果中计算。
故障处理
- 如果有ES集群单节点掉出集群不要慌张ES有自愈的能力，你只需要保证集群稳定，磁盘充足即可自动修复。
- 如果集群突然大多节点掉出集群，且出现分片丢失，那你需要考虑分片丢失是否能够接受，如果不能你可以通过同时停止全部节点，并启动全部节点进入时间门来尝试恢复全部数据。
- 正常情况下少数节点掉出集群，导致一些只读的分片丢失，可以把这些掉出的节点重新加入回集群即可恢复分片。
http://nginxs.blog.51cto.com/