Elasticsearch聚合查询，提高系统查询、导出性能_es的聚合查询的性能瓶颈在哪里

「扫码关注我，面试、各种技术（mysql、zookeeper、微服务、redis、jvm）持续更新中～」

随着业务的发展，线上生产环境数据量猛增，财务信息一个表的数据自从2008年系统上线以来已接近7千万，而且现在每天的增量也越来越快，由于业务中存在退费场景，所以历史财务数据也不容易归档处理。但是财务应用场景中含有大量的查询和导出，显然，将财务数据都存储在Mysql（建议单表数据量不超过2千万）中已经满足不了实际应用场景。

如何解决财务数据的查询和导出问题成为我们必须解决的一个难题，经过技术选型，我们最终选择了数据依然存储在Mysql（需要支持事务）中，使用ES来聚合数据进行查询。

那如何将数据从Mysql同步到ES并保证数据一致性是重点。一共梳理出来以下几种同步方式：
1.数据库建触发器方式，但是影响系统性能；
2.对数据行进行MD5加密对比，也会影响系统性能；
3.采用MQ方式增量新增，但增加了系统复杂度，同时需要保证MQ精准投递、消费；
4.根据时间戳定时任务同步，但是需要保证时间戳实时更新；
5.利用cancel监听binlog动态新增，但是存在cancel单点问题，同时系统复杂度会增高。

经过和运维沟通，采用binlog方式同步，由于涉及到老数据源（按照分校分库）太多，而且需要引入cancel中间件还需要进行数据映射，成本较高，所以我们采用定时任务Elastic-job分片（城市分片）进行同步，根据修改时间时间戳新增或者修改的变化每1分钟进行数据同步，同时在ES中需要按照ID进行新增或覆盖。

接下来就是如何保证数据库和ES数据的一致性，这是非常重要的。主要通过2步来完成，1.同步ES时建立了一个同步log表，记录下同步开始时间和结束时间，结束时间只有当ES返回同步成功当时候才进行更新，这样来保证即使中间同步过程出现问题，下次再同步时可以将上次未完成同步的数据接着进行同步。如果同步ES没有问题的话，取下次同步的开始时间为上次同步的结束时间；2.每天凌晨通过定时任务对前一天ES同步的数据和Mysq中新增或修改的数据条数进行check，如果同步条数不一致的话，将会将前一天的数据重新进行同步。

以上是实现Mysql同步ES的主要过程，但是还有许多优化的点，比如：
1.数据的实时性，现在数据会有1分钟延迟，后续会增加MQ直接监听数据的新增或修改并推送ES；
2.ES查询和导出服务是通过Dubbo采用RPC的方式对外提供服务，会存在链接超时和导出数据量大小限制的问题（现在只能批次导出）；
3.现在数据量猛增，数据存在Mysql中需要考虑分库、分表处理，不然以后同步ES数据查询时性能会有一定的影响。