如何处理mysql每月5亿的数据？

Question

这是个面试问题

一个电信计费系统，有一个互联网信息表(phone_number，start_time，stop_time，time_lasting，half )，每月有5亿条记录(2G)，每条记录大小为300 K，当人们使用4G上网时插入和更新，每次更新帐户余额(166写/S)，人们将从5*6=3000万(保存半年数据)查询他们的互联网详细信息。

question1:how to use mysql to handle these data?
quesiton2:how to optimize insert and update?
question3:how to optimize query ?

我的观点(我不正确)1.插入和更新是一个事务，所以每天使用InnoDB引擎2.分区表3.我需要redis或任何东西来帮助加速插入和更新吗?4.我不知道如何处理这个查询优化

非常感谢

Answer 1

计划A: ENGINE=InnoDB，有以下具体建议：

由于您在6个月后进行清除，我建议使用每周分区的PARTITION BY RANGE (TO_DAYS(...))。每周，把最古老的和REORGANIZE的“未来”放入“下周”和“未来”。见详细信息。

按日分区会导致分区太多，因此效率低下。而且，放弃一周的数据和一天的价值一样容易。

a_vlad是对的，分区不一定对查询有帮助。但这对于基于时间的清洗来说是很好的。

200 m*300 K更像2T。数学错误在哪里？可能是300 B？你是在暗示一个固定长度的行吗？别。

对于一张唱片来说，300 it似乎太大了--你在里面保存着什么？认真考虑将任何重复列标准化。

提供暂定SHOW CREATE TABLE和主要查询(insert/update/delete)。还不清楚是否需要对应用程序进行任何更新或删除。

166次写入/秒正在推动旋转驱动器的极限。要么使用带有电池的硬件RAID-5，写缓存，要么使用SSD。

我建议你调整一下我的高速摄食博客中的建议。这讨论了一种技术，以获得超过166写/秒。(请记住，峰值负载将远远高于166。)

B计划: NDB集群。(对不起，我没有具体的建议。但NDB是为电信设计的。)

瑞迪斯？这又增加了另一个动人的部分--更多的事情会出错。而且，假设您的流量是合理一致的，任何缓冲方案都不会带来什么好处。

MySQL框应该与客户端框(Es)分开。您应该设计客户端框(web服务器？)要想具有可伸缩性

Answer 2

有很多变体。

1. 分区--不是从错误的查询中获得帮助，而是会使情况变得更糟。
2. 拆分操作--在主程序上写入，所有读取(特别是用户)-在从站上
3. 关于只需插入更新的主优化结构，这些索引确实需要改进更新。
4. 关于从(S)-选择操作的索引
5. 查询必须尽可能减少行数--依赖于逻辑，但它需要分析查询和索引基数( user_id、日期、位置等)。
6. 然后再问一个好主意

每一张唱片需要300？这张表里也存储了什么。将表拆分为2的好主意

当然，它只是顶层，总是需要更多的应用程序和环境的细节。