如果有条件，尽可能使用SSD硬盘， 不错的CPU。ES的厉害之处在于ES本身的分布式架构以及lucene的特性。IO的提升，会极大改进ES的速度和性能
1.当机器内存小于64G时，遵循通用的原则，50%给ES，50%留给lucene。 2.禁止swap，一旦允许内存与磁盘的交换，会引起致命的性能问题。 通过： 在elasticsearch.yml 中 bootstrap.memory_lock: true， 以保持JVM锁定内存，保证ES的性能。
倒排索引满足了关键字搜索的效率，但是对于从另外一个方向的相反操作并不高效，比如聚合（aggregations）、排序（Sorting）和字段的全值查询等时候需要其它的访问模式。
需求开的字段
1，需要聚合的字段，包括sort，agg，group，facet等 2，需要提供函数查询的字段 3，需要高亮的字段，这个确实能加速，但是散仙并不建议把高亮放在服务端程序做，建议放在前端实现，不容易出错而且总体性能比服务端高 4，需要参与自定义评分的字段，这个稍复杂，大多数人的场景中，不一定能用到，后面会单独写一篇文章介绍。
针对字段开启doc_values
docValeus只能针对全值匹配建立索引，不会分词后再建立正排索引
数据快照保存：这可以告诉 Elasticsearch 需要保持搜索的上下文环境多久（参考Keeping the search context alive），如 ?scroll=1m 使用上面的请求返回的结果中包含一个 scroll_id，这个 ID 可以被传递给 scroll API 来检索下一个批次的结果 数据快照不变：同时这个查询快照是不会变的，如果后续对文档的改动（索引、更新或者删除）都只会影响后面的搜索请求
生成滚动
POST /twitter/tweet/_search?scroll=1m { "query": { "match" : { "title" : "elasticsearch" } } }结果返回
{ "_scroll_id": "DnF1ZXJ5VGhlbkZldGNoBQAAAAAAAAABFlV2SjExVXdpUmwtNVFTOThNaWFRTVEAAAAAAAAAAhZVdkoxMVV3aVJsLTVRUzk4TWlhUU1RAAAAAAAAAAMWVXZKMTFVd2lSbC01UVM5OE1pYVFNUQAAAAAAAAAEFlV2SjExVXdpUmwtNVFTOThNaWFRTVEAAAAAAAAABRZVdkoxMVV3aVJsLTVRUzk4TWlhUU1R", "took": 879, "timed_out": false, "_shards": { "total": 5, "successful": 5, "skipped": 0, "failed": 0 }, "hits": { "total": 136982, "max_score": 1, "hits": [ ] } }利用滚动
POST /_search/scroll { "scroll" : "1m", "scroll_id" : "c2Nhbjs2OzM0NDg1ODpzRlBLc0FXNlNyNm5JWUc1" }Ps：每次請求都會產生一個 _scroll_id，只有最近的 _scroll_id 才能被使用；如果请求指定了聚合（aggregation），仅仅初始搜索响应才会包含聚合结果。
扫描室滚动参数，用于避免在深圳分頁中，请求页对于数据打分还有查询顺序的考虑，从而提高性能
POST /twitter/tweet/_search?scroll=1m&search_type=scan { "query": { "match" : { "title" : "elasticsearch" } } }扫描式的滚动请求特点： （1）不算分，关闭排序。结果会按照在索引中出现的顺序返回 （2）不支持聚合 （3）初始 search 请求的响应不会在 hits 数组中包含任何结果。第一批结果就会按照第一个 scroll 请求返回。 （4）参数 size 控制了每个分片上而非每个请求的结果数目，所以 size 为 10 的情况下，如果命中了 5 个分片，那么每个 scroll 请求最多会返回 50 个结果。 （5）如果你想支持打分，即使不进行排序，将 track_scores 设置为 true。
手动删除滚动查询，避免内存消耗
删除一个
DELETE /_search/scroll { "scroll_id" : ["c2Nhbjs2OzM0NDg1ODpzRlBLc0FXNlNyNm5JWUc1"] }删除多个
DELETE /_search/scroll { "scroll_id" : ["c2Nhbjs2OzM0NDg1ODpzRlBLc0FXNlNyNm5JWUc1", "aGVuRmV0Y2g7NTsxOnkxaDZ"] }删除所有
DELETE /_search/scroll/_allGET参数删除
DELETE /_search/scroll/DXF1ZXJ5QW5kRmV0Y2gBAAAAAAAAAD4WYm9laVYtZndUQlNsdDcwakFMNjU1QQ==,DnF1ZXJ5VGhlbkZldGNoBQAAAAAAAAABFmtSWWRRWUJrU2o2ZExpSGJCVmQxYUEAAAAAAAAAAxZrUllkUVlCa1NqNmRMaUhiQlZkMWFBAAAAAAAAAAIWa1JZZFFZQmtTajZkTGlIYkJWZDFhQQAAAAAAAAAFFmtSWWRRWUJrU2o2ZExpSGJCVmQxYUEAAAAAAAAABBZrUllkUVlCa1NqNmRMaUhiQlZkMWFB指定一个slice参数，做拆分滚动查询； max
GET /twitter/_search?scroll=1m { "slice": { "id": 0, ① "max": 2 ② }, "query": { "match" : { "title" : "elasticsearch" } } } GET /twitter/_search?scroll=1m { "slice": { "id": 1, "max": 2 }, "query": { "match" : { "title" : "elasticsearch" } } }分片数量一旦确定，所以不可以修改，此时就需要重建索引
创建一个new_index，指定好正确的mapping和分片数量即可
POST _reindex { "source": { "index": "old_index" }, "dest": { "index": "new_index" } }文档id发生冲突时间，elasticsearch强制性的将文档转储到目标中，覆盖具有相同类型和ID的任何内容
POST _reindex { "source": { "index": "old_index" }, "dest": { "index": "new_index", "version_type": "internal" } }需要迁移的数据量过大时，我们会发现reindex的速度会变得很慢，因为重复的网络请求比较多
POST _reindex { "source": { "index": "source", "size": 5000 }, "dest": { "index": "dest", "routing": "=cat" } }配置依据
批量大小取决于数据、分析和集群配置，但一个好的起点是每批处理5-15 MB 1）从大约5-15 MB的大容量开始，慢慢增加，直到你看不到性能的提升。然后开始增加批量写入的并发性(多线程等等)。 2）使用kibana、cerebro或iostat、top和ps等工具监视节点，以查看资源何时开始出现瓶颈。如果您开始接收EsRejectedExecutionException，您的集群就不能再跟上了:至少有一个资源达到了容量。 要么减少并发性，或者提供更多有限的资源(例如从机械硬盘切换到ssd固态硬盘)，要么添加更多节点。
每个Scroll请求，可以分成多个Slice请求，可以理解为切片，各Slice独立并行
POST _reindex?slices=5&refresh { "source": { "index": "twitter" }, "dest": { "index": "new_twitter" } }配置依据
1）slices大小的设置可以手动指定，或者设置slices设置为auto，auto的含义是：针对单索引，slices大小=分片数；针对多索引，slices=分片的最小值。 2）当slices的数量等于索引中的分片数量时，查询性能最高效。slices大小大于分片数，非但不会提升效率，反而会增加开销。 3）如果这个slices数字很大(例如500)，建议选择一个较低的数字，因为过大的slices 会影响性能。
