*根据索引模板自动创建索引库

*定时创建7天的索引库

*提供orm爬虫创建索引接口,多线程批量创建

*IK分词器热分词

*接口限流控制RateLimiter

*6.x以上版本不支持单个index创建多个type

##

##约定说明

*indexName索引名称命名空间

*indexType文档名称

*schema索引键值对

*data索引内容

*version索引版本

*fields输出键值对

*keywords全文检索关键词

*filter过滤规则

*sort排序规则,默认文本相似度排序

*distinct聚合字段

*field完全匹配字段

*score自定义文本得分

##

##接口地址说明

*查询模板mapping

1)indexName模板名称

2)indexType索引表

>http://127.0.0.1:9599/v1/es/schema/{indexName}/{indexType}/templateMapping

*删除模板

1)indexName模板名称

>http://127.0.0.1:9599/v1/es/schema/{indexName}/delSchema

*创建媒体资源模板

>http://127.0.0.1:9599/v1/es/schema/mediaSchema

*查询索引库下边的索引表

1)indexName索引库

2)indexType索引表

>http://127.0.0.1:9599/v1/es/schema/media-2018-06-09/news/mapping

*删除索引

>http://127.0.0.1:9599//v1/es/schema/.monitoring-es-6-2018.06.08/deleteIndex

##

##Elasticsearch优化

*FilterCache

Filtercache是用来缓存使用过的filter的结果集的，需要注意的是这个缓存也是常驻heap，无法GC的。默认的10%heapsize设置工作得够好了，如果实际使用中heap没什么压力的情况下，才考虑加大这个设置。

*FieldDatacache

对搜索结果做排序或者聚合操作，需要将倒排索引里的数据进行解析，然后进行一次倒排。在有大量排序、数据聚合的应用场景，可以说fielddatacache是性能和稳定性的杀手。这个过程非常耗费时间，因此ES2.0以前的版本主要依赖这个cache缓存已经计算过的数据，提升性能。但是由于heap空间有限，当遇到用户对海量数据做计算的时候，就很容易导致heap吃紧，集群频繁GC，根本无法完成计算过程。ES2.0以后，正式默认启用DocValues特性(1.x需要手动更改mapping开启)，将fielddata在indexingtime构建在磁盘上，经过一系列优化，可以达到比之前采用fielddatacache机制更好的性能。因此需要限制对fielddatacache的使用，最好是完全不用，可以极大释放heap压力。这里需要注意的是，排序、聚合字段必须为notanalyzed。设想如果有一个字段是analyzed过的，排序的实际对象其实是词典，在数据量很大情况下这种情况非常致命。

*BulkQueue

BulkQueue是做什么用的？当所有的bulkthread都在忙，无法响应新的bulkrequest的时候，将request在内存里排列起来，然后慢慢清掉。一般来说，Bulkqueue不会消耗很多的heap，但是见过一些用户为了提高bulk的速度，客户端设置了很大的并发量，并且将bulkQueue设置到不可思议的大，比如好几千。这在应对短暂的请求爆发的时候有用，但是如果集群本身索引速度一直跟不上，设置的好几千的queue都满了会是什么状况呢？取决于一个bulk的数据量大小，乘上queue的大小，heap很有可能就不够用，内存溢出了。一般来说官方默认的threadpool设置已经能很好的工作了，建议不要随意去“调优”相关的设置，很多时候都是适得其反的效果。

*IndexingBuffer

IndexingBuffer是用来缓存新数据，当其满了或者refresh/flushinterval到了，就会以segmentfile的形式写入到磁盘。这个参数的默认值是10%heapsize。根据经验，这个默认值也能够很好的工作，应对很大的索引吞吐量。但有些用户认为这个buffer越大吞吐量越高，因此见过有用户将其设置为40%的。到了极端的情况，写入速度很高的时候，40%都被占用，导致OOM。

*ClusterStateBuffer

ES被设计成每个Node都可以响应用户的api请求，因此每个Node的内存里都包含有一份集群状态的拷贝。这个Clusterstate包含诸如集群有多少个Node，多少个index，每个index的mapping是什么？有少shard，每个shard的分配情况等等(ES有各类statsapi获取这类数据)。在一个规模很大的集群，这个状态信息可能会非常大的，耗用的内存空间就不可忽视了。并且在ES2.0之前的版本，state的更新是由MasterNode做完以后全量散播到其他结点的。频繁的状态更新都有可能给heap带来压力。在超大规模集群的情况下，可以考虑分集群并通过tribenode连接做到对用户api的透明，这样可以保证每个集群里的state信息不会膨胀得过大。

*超大搜索聚合结果集的fetch

ES是分布式搜索引擎，搜索和聚合计算除了在各个datanode并行计算以外，还需要将结果返回给汇总节点进行汇总和排序后再返回。无论是搜索，还是聚合，如果返回结果的size设置过大，都会给heap造成很大的压力，特别是数据汇聚节点。超大的size多数情况下都是用户用例不对，比如本来是想计算cardinality，却用了termsaggregation+size:0这样的方式;对大结果集做深度分页；一次性拉取全量数据等等。

在开发与维护过程中我们总结出以下优化建议:

尽量运行在Sun/OracleJDK1.7以上环境中，低版本的jdk容易出现莫名的bug，ES性能体现在在分布式计算中，一个节点是不足以测试出其性能，一个生产系统至少在三个节点以上。

倒排词典的索引需要常驻内存，无法GC，需要监控datanode上segmentmemory增长趋势。

根据机器数，磁盘数，索引大小等硬件环境，根据测试结果，设置最优的分片数和备份数，单个分片最好不超过10GB，定期删除不用的索引，做好冷数据的迁移。

保守配置内存限制参数，尽量使用docvalue存储以减少内存消耗，查询时限制size、from参数。

如果不使用_all字段最好关闭这个属性，否则在创建索引和增大索引大小的时候会使用额外更多的CPU，如果你不受限CPU计算能力可以选择压缩文档的_source。这实际上就是整行日志，所以开启压缩可以减小索引大小。

避免返回大量结果集的搜索与聚合。缺失需要大量拉取数据可以采用scan&scrollapi来实现。

熟悉各类缓存作用，如fieldcache,filtercache,indexingcache,bulkqueue等等，要设置合理的大小，并且要应该根据最坏的情况来看heap是否够用。

必须结合实际应用场景，并对集群使用情况做持续的监控。