MYSQL数据库需要创建两个表来分别存放流量刷新日志及异常数据日志（我们是电信业务，数据量很大），如何设计
0
悬赏园豆：30
[已解决问题]
解决于 2017-08-16 09:46
MYSQL数据库需要创建两个表来分别存放接口调用日志及异常数据日志（我们是电信业务，数据量很大），以前没有做个类似的设计，不知道如何设计才合理，不想再后面给别人留坑，所以想请教一下各位遇到过类似问题有好的建议的人。
就拿第一个表“接口调用日志表”来说：
主要用来存放各种渠道对卡片流量的刷新日志（包括定时任务刷新，各种平台手动刷新都要记录，我们平台现有卡大概是60多万，定时任务的刷新每天都有，所以该表每日的增量必定是60w+，我们的业务增长很快，年底估计卡片能达到150多万，那么每天的增量就达到150w+，以此类推，总之该表的增量受很多因素的影响，会越来越大，并且公司希望能保存6个月的历史数据，以便查询）
在说一下我现在的环境：
数据库版本:MYSQL5.6
环境：阿里云上的RDS实例
硬件：两个实例，读写分离各一个（两个实例磁盘空间15G，master数据库已用67% slave数据库已用62%）
本人对这块接触的不是很多，由于开发进度的需要这个表有点急，希望各位给出自己的建议（包括建表的建议和空间的建议等）并说明原因。非常感谢！
最佳答案
0
日志别放数据库.放文件系统.你也知道自己量大.就想些优化的法子.
有的业务系统一天几个G的日志.你什么数据库能放的下.
收获园豆：10
嗯嗯，非常感谢你的建议，这个表我了解了主要是给我们排查问题用的，可以存文件。
但是还有另一个表“异常数据日志表”，这个表需要在前台能够查到数据，虽然比上一个表小，但是增量也挺大的。这个有什么建议吗？
其他回答(3)
0
说个法子，日志系统没必要一定可以在线查询6个月的（注意是在线）。
云服务器贵的很，你完全可以每天把日志下载到你们公司内网服务器。
云上就保存一天日志好了。
收获园豆：5
嗯嗯，非常感谢你的建议，这个表我了解了主要是给我们排查问题用的，可以存文件。
但是还有另一个表“异常数据日志表”，这个表需要在前台能够查到数据，虽然比上一个表小，但是增量也挺大的。这个有什么建议吗？
@初八见: 一样，你们前台可以使用内部服务器啊。
一台服务器专门做业务，一台服务器专门做服务，不同的业务不放在一台服务器，也方便扩展。
0
问题是：这两种日志需要经常查询和分析么？
收获园豆：5
不经常，只是偶尔排查问题用的。
@初八见: 那没必要放数据库里。可考虑每天生产一个日志文件，需要排查问题时，直接分析这个文件就行了。
0
15G你放的了这么多？这种肯定要取舍，要性能还是要省空间，看你的情况空间好像更宝贵些，那么只要是能够支持写入量随便你怎么放都可以，这个仅作为最原始的备份，不要指望在上面查任何东西，只是做灾备。
在写入原始表后同步一份到队列里面来，后面写到自己的服务器上，这块就可以慢慢玩了，看样子这个卡片应该就是区分用户的关键了，那你按照这个做个普通hash分片写入（这块建议不要考虑什么后期在线迁移数据啥的，那种需要的运维水平相当高），hash的算法这个需要好好掂量下，找dba什么的估算下1年需要保存多少量的数据，如何把过期的数据切到冷备或者如何删除，举个简单的例子：奇数年份使用一个hash算法，对应一堆db，偶数年份使用另一个算法，对应另一堆db（两遍数据做同步，但后面一堆db会定时把已过期的数据删掉），这样在任意时刻对应db的数据量都不至于太多，切换时也不会出现丢数据的问题。
分片分表后最好能够让单表数据量在你设定的时间内小于百万级，当然你查询量如果真的小的话上1到2个数量级也没什么问题。
换成文件方式也类似，但也需要额外辅助空间来记录文件偏移量和时间的关系。
收获园豆：5
