elasticsearch从集群到API使用的一些最佳实践

1、数据同步方案。

方案A一定时周期性读MySQL写ES，周期过短读写两方压力都大，过长则数据同步延迟可能不能满足需求，无论后台管理有无操作都会读MySQL写ES，但是技术成本低代码量小。方案B数据同步延迟较低，依赖MQ，也需要代码消费消息对ES增删改或（logstash消费消息写入ES？）。基于方案A

方案A

方案B

2、数据同步组件调优

阿里dataX+Linux系统的crontab：github下载https://github.com/alibaba/DataX ，700M+，解压后达1G，可以删除plugin目录下不必要的redear/writer相关组件，只保留需要的mysqlreader及eswriter，整个解压后包就30M左右了。如果公司用ELK套件，可以考虑logstash，但是logstash赶脚比dataX重多了，参考https://www.cnblogs.com/leeolevis/p/ELK-ElasticSearch-Logstash-Mysql-NetCore.html

3、xpack监控日志索引优化

xpack可以监控集群健康、集群负载、主机CPU、内存、磁盘、JVM堆栈、索引大小、索引文档数、数据分配情况、索引速率等，很有用。但xpack监控默认每天会参数大量日志索引，这些日志索引或占用大量磁盘及小量内存，每天的合起来也不少啊。网上一时没有找到xpack监控信息采集及清除策略配置。只能采取crontab定时执行curl请求集群暴露给我们的HTTP删除索引接口=》https://mp.csdn.net/postedit/89397518

4、索引创建之setting与mapping基本优化

A、刷新周期：默认刷新周期1s，调整至较大数值；需要及时刷新使用Java API来刷新；

B、mapping中不需要索引的字段设置index：false，不需要text字段score设置norms:false,不需要match_phrase的索引禁用positions搜索index_options:"freqs" 

C、使用合理的数据类型能byte就不用integer，可以节省内存磁盘

5、ES之Java最佳实践

A、Java代理构建请求参数时fetch你需要的field，类似MySQL，不要select *，只取你需要的field

B、对于不需要根据相关度排序的请求参数请设置到filter中，需要支持相关度排序的才设置到query中，注意如果设置了非_score的其它字段排序，请求会计算相关度，但并不会按相关度排序，需要手动增加按_score降序排序（二级排序） =》https://mp.csdn.net/postedit/88998957

C、性能不敏感的接口推荐使用spring-data-elasticsearch的API，比原生的transport 的API要好用，特别是结果集处理，它是在原生api的上层封装，会稍微有点点额外性能消耗；如果是性能敏感的接口还是用原生transport API并手动处理一下结果集比较好。

D、如果请求较复杂，建议请求参数构建与结果集处理抽取独立的private方法，避免臃肿。