之前没有接触过elastic ，但是对这个名字仰慕已久，期望着有朝一日目睹一下他的芳容，见识一下她的威力。机缘巧合，最近一个项目需求的使用场景正好和elastic 契合。于是我开始尝试着去揭开她的面纱……
es中的数据来源有两种，一种是通过调度任务周期性的将最新收集的数据导入es ， ps： hive 2 es的模式。另外一种是针对庞大的历史数据，通过spark作业来 实现sparkSql 2 es的模式。接下来总结一下我们路上碰到一些问题和解决办法。
以下优化的硬件配置 背景：
5 nodes，
5 shards
1 replica
4 core
8G mem
普通硬盘
1.产品需求到方案设计。
往往一些性能问题都是当初的存储方案设计失误导致的。这里说的存储方案即 如何合理的规划集群、机器、索引、shard、replica、存储空间，我们的一个目标和原则：理性的衡量索引的数量和单索引下的doc 数量。我们公司对于一般的业务提供的es集群的配置：5nodes，4 core，8G mem
（1）衡量单个索引下的doc数来创建索引：可以按照业务的类型、按照月份
（2）单索引默认配置shards 为5 ，如果数据量非常大，分片多一些。分片越多在查询中涉及到的合并和聚合需要更多的资源。
（3）replica 默认1，负分片起到容灾的作用，数量越大那么数据同步的IO就会越大
2.写的性能优化
（1）通过设置副本数为0，减少主分片和副分片之间数据同步的IO资源消耗（针对写操作较集中的业务场景，）
（2）修改索引刷新频率，默认值1s刷新一次。可以调整后10s刷新一次，减少数据刷新占用的系统性能 （适合查询的实时性要求不高的场景）
（3）单次写入es的数据量不要太大建议5-15MB，否则会EsRejectedExecutionException，就说明已经到达节点的瓶颈了，就需要减少并发或者升级硬件增加节点。
（4）使用用bulk导入大量的数据
3.查询优化
（1）routing 的设置
系统计算索引存储的位置是通过公式来实现的：shard_num = hash(_routing) % num_primary_shards ，系统默认是按照索引的Id来做routing 。如果可以按照业务场景中的某个字段来做routing，那么我们根据这个字段来搜索的时候可以很快的定位到相应的shard，减少全索引扫描，从而极大的提高性能。但是需要注意的是 routing一旦创建，那么num_primary_shards是不可以轻易的改变的，否则routing的策略就会失效。
（2）使用filter
当进行精确查询时，过滤器filter是十分重要的，因为它们效率非常高，过滤器不计算相关性（直接跳过了整个记分阶段）而且很容易进行缓存。
（3）使用segment 合并
lucene在插入和更新数据的时候会生成很多segment来支持实时查询，因此会产生很多segment碎片，索引在搜索的时候会查询多个segment，进行合并后可以减少segment的查询次数，提升速度。建议max_num_segments＝1
（4）根据业务情况缩小查询范围
4 聚合和排序
Elasticsearch通过反向索引做搜索，通过DocValues列式存储做分析，将搜索和分析的场景统一到了一个分布式系统中,通过设置DocValues