1回答

Moody

2021-06-27

mq的问题倒不大，MySQL的问题比较大：

这个业务的数据量太大了，按每秒500条计算，每天的数据量4000万，必须要分表，单个分片最好控制在1000万条，也就是每6个小时一个分片。一个64分片的集群能存储16天的数据。

这样的架构，好处是查询性能好，可以跑事务，坏处就是成本比较高，每个分片能承载的数据量有限。

如果需要更大的存储量，可以看看Hadoop、Spark这样的大数据仓库，坏处是不能跑事务，小查询没有MySQL快，但是可以跑大型的分析SQL语句。

还有要考虑的是，每秒存好几百条数据，是否可以有改进的地方?比如，是否可以按照一个默认规则生成文件？比如文件名=用户名+设备ID+时间戳。这样文件名根本不用存库，业务到时候自己推算文件名，去文件系统找就是了。

如果这样不可行，查询性能要求不高的时候，考虑把每100条数据写到一个文件里，这样文件系统数据量并没变，但数据库条目减少了100倍。反正原则就是：数据库的条目是很珍贵的资源，要尽量缩减数据条目，把能推算的、能合并的、尽量优化一下。

0

0