刚接手系统的时候,发现过亿的操作日志写在 MySql的一张表中,主要是记录用户登录,做了那些动作(增删改查),随之便做了如下处理(索引、sql均已优化过了):
1、刚开始接手以为查询并不频繁,做了分区,后来发现查询很频繁;
2、对数据做了分表,一个月一个表,发现夸月查询又很频繁,并且每个用户都强烈要求看至今所有的数据;
3、这些查询会集中在某个点并发查询,会产生大量的慢查询导致影响到其他业务,所以对这些查询频繁的用户做了redis数据缓存;
以上做完之后,系统算是稳定下来了,但随着用户的增加单表数据也会随之增加,并且在某个点同样会爆发高并发访问数据库的情况,近期在考虑是否可以用搜索引擎来做这个事情,因为历史数据是不可变的,思路如下,请大神指点:
1、将此模块单独出一个微服务
2、创建总索引
3、每天定时增量索引,并将增量索引数据搬入和业务隔离的日志数据库中对应历史表(同样每个月创建一个表)
4、在查询的时候有多种情况的考虑,对当天的数据进行数据库查询,对历史数据进行搜索引擎索引查询,若夸有当天和历史数据的查询,进行分别查询后结果合并
不知此方法是否可行,因为我在网上找了很久,都并没搜索到使用搜索引擎这种方法,全都是分库分表,或者用hbase等解决方案,所以担心是否会有弊端。