优化
说实话，es 性能优化是没有什么银弹的，啥意思呢？就是不要期待着随手调一个参数，就可以万能的应对所有的性能慢的场景。也许有的场景是你换个参数，或者调整一下语法，就可以搞定，但是绝对不是所有场景都可以这样。
- filesystem cache的访问速度要比磁盘文件快，尽量放到cache上。
- cache中的数据尽量有效，没用的多余字段不需要放在es中。完全可以返回一个id，然后用id去database中去查。
- 假如返回字段不多的情况下，且要在数
- 数据预热，比如定时获取一下，让数据进入cache
- 冷热数据处理，定时剔除冷数据
- 尽量不要在es中做复杂查询
- 可以将最终的数据存入es，字段很多的情况下，可以只在es存入有效字段，将复杂查询的字段放入其查询库或其他库中。让然，这加大了数据的一致性，需权衡利弊，以及财力。
- es不要做分页
- 假如你每页是 10 条数据，你现在要查询第 100 页，实际上是会把每个 shard 上存储的前 1000 条数据都查到一个协调节点上，如果你有个 5 个 shard，那么就有 5000 条数据，接着协调节点对这 5000 条数据进行一些合并、处理，再获取到最终第 100 页的 10 条数据。
- 分布式的，你要查第 100 页的 10 条数据，不可能说从 5 个 shard，每个 shard 就查 2 条数据，最后到协调节点合并成 10 条数据吧？你必须得从每个 shard 都查 1000 条数据过来，然后根据你的需求进行排序、筛选等等操作，最后再次分页，拿到里面第 100 页的数据。你翻页的时候，翻的越深，每个 shard 返回的数据就越多，而且协调节点处理的时间越长，非常坑爹。所以用 es 做分页的时候，你会发现越翻到后面，就越是慢。
- 可以用scroll api，下拉式翻滚，但不能随意跳转。
- scroll 会一次性给你生成所有数据的一个快照，然后每次滑动向后翻页就是通过游标 scroll_id移动，获取下一页下一页这样子，性能会比上面说的那种分页性能要高很多很多，基本上都是毫秒级的。但是，唯一的一点就是，这个适合于那种类似微博下拉翻页的，不能随意跳到任何一页的场景。