elasticsearch集群的使用总结

elasticsearch集群的使用总结

目前在维护的elasticsearch集群保存了超过百亿的数据，日常调用也超过几千万，这里总结一下使用中的心得体会。总的来说elasticsearch的分布式性能强劲，但是也需要使用者深入的理解原理，精心维护，合理使用。优化上不仅有elasticsearch设置合理的参数，还有使用上的约束。

参数优化

关闭系统的swap

swap虚拟内存，安装elasticsearch的服务器都是高配服务，全部关闭虚拟内存

master和data节点分开部署

设置合理的内存大小

官方建议的内存大小最小为1G,最大不要超过32G,

Don’t set Xms and Xmx to above the cutoff that the JVM uses for compressed object pointers (compressed oops); the exact cutoff varies but is near 32 GB. You can verify that you are under the limit by looking for a line in the logs like the following:

heap size [1.9gb], compressed ordinary object pointers [true]

32G 的大小涉及java的指针压缩，理论上也可以设置超过32G，但是需要分配更多的内存。并没有实践过。我们将内存大小设置为31G

修改文件句柄限制

这里的如果太小，启动时也会提示文件句柄数太小。不过修改文件句柄数有两种方式，一种是永久生效的，需要服务器重启才能生效；一种是临时生效的，不需要重启即可生效，记得两种都修改，避免服务器故障重启后，服务无法启动

性能更高的磁盘

建议单独分配磁盘只给elasticsearch实例使用，如果有条件，直接ssd

同一台机器安装多个实例

由于部署elasticsearch的机器是高配服务，可以在上面部署多个节点充分利用机器性能，安装多个实例，可以在elasticsearch启动的命令中指定不同实例的配置文件即可，无需复制多个包，可以减少安装elasticsearch插件的管理成本

使用优化

限制返回大数据

elasticsearch并不是适合返回大量的数据，更适合的是匹配查询条件的少量数据，因此我们要求所有的明细查询都必须有时间参数，可以很好的避免返回大量数据（elasticsearch默认也有深翻页限制，最多10000条）

集合拆分

官方建议的单个分片不要超过40g, 曾经因为意外产生过一个超大的集合，每次写入都会出现查询超时和服务器告警，接着就是运维的连环call，超大的分片的集合会给elasticsearch的节点带来巨大的压力，可以通过按日或者按月来拆分集合

只存索引不存数据

在新建elasticsearch集合时，指定配置source 设置为false，在elasticsearch中只存索引，将数据保存在hbase中，利用hbase的存储性能减轻elasticsearch的存储压力，将elasticsearch和hbase搭配使用，一条数据在写入时，在elasticsearch中只保存索引数据和hbase中的rowkey（查询条件相关的字段），在hbase中保存具体的数据，查询时根据查询条件在es中查询到rowkey，在用rowkey去hbase中查询原始数据，再返回给请求方，减少elasticsearch的存储压力，不过这种方式需要开发者对elasticsearch和hbase都比较熟悉，要求相对高一点，这也是一种常见的hbase的二级索引方案