记得某天与某大牛聊天，得知他在玩这个东西苦于公司资源不足，无法搭建一个稍微有点规模的集群，但是从中也学习到了很多东西，回去就开干了。
说实话，Es性能优化是没有什么银弹的，啥意思呢？就是不要期待着随手调一个参数，就可以万能的应对所有的性能慢的场景。也许有的场景是你换个参数，或者调整一下语法，就可以搞定，但是绝对不是所有场景都可以这样。「好像MySQL」
场景
1. 系统日志 --- Docker技术的兴起带动了周边一圈生态的发展，Es也同样吧「要不平时真的场景不多的」
2. 全文索引服务 --- 大量的搜索服务从前要不用MySQL「全文索引真的不合适」，要不用MongoDB，要么自己基于Luncene搞「这个没玩过」，最好可以让写入方有rebuild index的功能，维护者搞也行写个小工具，场景例如关键字审核、快速查询、去重服务
Shard
Es的分片个数在它落地的时候就确定了个数后期无法更改，就给到前期确定到底开多少个带了巨大的问题「建议一定要和研发确认个数，要不后期加机器、加盘都没用」。
一般日志都是按天存放，在这边其实个人不是很喜欢这样的设计，各种各样的日志有大有小其实会造成大量的shard，而且Es的balance是基于shard来做的，那样就带了对于日志系统就是巨大的打击。
1. 当触发新建index的时候我们刚刚扩容集群，例如集群data node 20台、每台8块盘，我们扩容到了25台，新index来了接着悲剧发生了，所有的index都聚合到了那几天新机器上面去了，如何规避算好添加机器的个数的问题，并且可以手工删除一些没用的索引。
2. index大小问题导致每台机器的每块盘无法充分利用的问题，这边可以参考GrayLog的一种处理方法，日志系统index按条数存放「这样其实是可以估算出数据占用空间问题的，并且可以差不多保证每个shard差不多大小，而且当系统突然压力大的时候可以及时扩缩shard个数充分利用集群Io资源」，至于存放时间不好估算问题，其实这样想研发突然打一堆说明啥已经不合理了是不是真的需要支持是需要商议的呢「当然尽可能存放更多」
Filesystem Cache
你往Es里写的数据，实际上都写到磁盘文件里去了，查询的时候，操作系统会将磁盘文件里的数据自动缓存到 filesystem cache 里面去。
Es 的搜索引擎严重依赖于底层的 filesystem cache，你如果给 filesystem cache 更多的内存，尽量让内存可以容纳所有的 idx segment file索引数据文件，那么你搜索的时候就基本都是走内存的，性能会非常高。
例如 Es 节点有 3 台机器，每台机器看起来内存很多，64G，总内存就是 64 * 3 = 192G。每台机器给 es jvm heap 是 32G，那么剩下来留给 filesystem cache 的就是每台机器才 32G，总共集群里给 filesystem cache 的就是 32 * 3 = 96G 内存。而此时，整个磁盘上索引数据文件，在 3 台机器上一共占用了 1T 的磁盘容量，es 数据量是 1T，那么每台机器的数据量是 300G。这样性能好吗？ filesystem cache 的内存才 100G，十分之一的数据可以放内存，其他的都在磁盘，然后你执行搜索操作，大部分操作都是走磁盘，性能肯定差。
归根结底，你要让 Es 性能要好，最佳的情况下，就是你的机器的内存，至少可以容纳你的总数据量的一半。「摘录于 es在数据量很大的情况下（数十亿级别）如何提高查询效率啊？」
参数
index.number_of_replicas「那是相当的影响性能」
cluster.routing.allocation.enable 「集群调整或者宕机的时候需要注意」
routing.allocation.total_shards_per_node
analyzed 「不用字段别开，全文索引服务要特别注意」
需要特别注意的个人建议如上，具体的大家自己直接看官方文档即可，主要出发点还是控制写入频率、简化index结构。「索引结构才是关键，出生的时候就决定了80%的性能了」
合并索引
elasticsearch-dump，Import and export tools for elasticsearch。思路就是导入导出「还能有啥」
总结
Es并没有官方描述的那么猛，不比监控系统「这个也很麻烦」，日志系统需要维护好了还是需要消耗大量精力的「比如日志是否需要限流，是否需要抽样，这是都需要在收集端来实现的，但是产出又不是那么明显」，小了随便玩，大了一切都不一样了。
全文索引业务，就一定要开慢查询「类似mysql玩法」，你的系统查的多了别人系统就不行了，只拿需要的，Es原理上面就这样内存里面最新的是快的，磁盘的上面的就看你Io了「此处建议SSD」。
网友评论