mysql 500w 某一项不重复 效率_MySQL储存海量数据到底有没有问题？

海量关系型数据的存储诉求

越来越多的企业在企业迁移上云时开始使用MySQL数据库业务存储数据，其中不乏包括从Oracle转型到MySQL的业务，这些业务往往对数据库的要求极高，包括且不仅包括：

1. 数据库稳定性
2. 数据库高可用
3. 数据库并发承载能力
4. 大量关系型数据的存储能力
5. ……

这里我并不想讨论以上1~3点，而是着重说一下：4.大量关系型数据的存储能力

网上一直流传MySQL不建议存海量数据，但是我相信，更多人没有思考过为什么会有这样的建议，而是默默接受了，在海量数据的场景，选择了分布式数据库。

其实，单表超过1亿，MySQL也可以正常存储，并出色的完成查询，我们的生产环境是验证过的(表1.8亿，列很少，结构非常稳定，没有DDL),但单个MySQL确实不推荐存储海量数据，建议单表500W-1000W

个人理解的主要原因为：

• 1.数据量大，在进行DDL时，几乎是毁灭级别的，虽然现在online DDL在逐渐完善，但仍有没办法进行online的操作，开销很大，由于业务需求，为表增加列，往往是不可避免的，虽然可以用预留字段的方式一定程度上规避这个问题，但不可能为每张表都预留字段，预留字段也不可能无限多
• 2.随着数据量的增长，索引的效率会越来越低(如insert的场景，insert当然和索引有关系，之后再单独写一篇文章吧)，这个问题即使在Oracle上也是尤其明显的；
• 3.备份恢复难，几千万甚至上亿的表，备份与恢复的时间都会非常长，在出现异常需要恢复时业务恢复时间变得不可控。

越来越多的用户意识到了这个问题，开始去使用分布式关系型数据库，目前仍然被讨论的比较多的是开源代表MyCAT，以及阿里云DRDS。

关于阿里云DRDS

有幸在2016年，深度参与了使用阿里云DRDS的上云项目，理解了DRDS的组成架构，由于业务上的需要，做过包括功能、扩展性、最大性能等测试，在高可用的场景中，将DRDS的node节点、管控节点，均进行过进程级kill、主机级poweroff等，测试下来，DRDS运行非常稳定。

目前我们生产环境通过DRDS的横向扩展能力，最大的单个DRDS实例已经存储了百亿级数据，峰值QPS达到10W。

生产业务峰值达到10W QPS

对比DRDS与开源分布式数据库解决方案：

• 从产品活力的角度来说，DRDS在2018-2019今年的今天版本迭代10余次，再去看其他分布式数据库解决方案，基本上已经停更。
• 从产品成熟度与易用度的角度来说，DRDS拥有全面化的操作、在线实时生效、完善的扩缩容解决方案，其他开源方案基本上是配置文件、手工操作的原始状态。
• 从产品支持的角度来说，DRDS有强大、专业、稳定的开发与维护团队，开源方案在使用前，要投入大量人员“吃透”这个产品，否则出现问题，几乎无法解决。

数据是企业的核心价值，数据库可以说是企业的命脉，在选择数据库上，要慎之又慎。

下次介绍一下DRDS的架构，以及在使用DRDS时，受到了分库键的限制，如何解决多维数据查询的问题。

仔细思考，你一定会有所收获。

欢迎关注：云架构那些事儿，专注实用性云架构分享与IT技术分享。