LAMP 架构应用上面提到的扩展技术，演变成了上图的可扩展的数据架构。应用侧通常是无状态计算，所以可以简单采取 Scale-out 的扩展方式，前置 Load Balancer 来进行流量调度。存储侧采取分库分表的方式来进行存储和计算的扩展，以及只读库的方式来对查询计算进行扩展。虽然各层具备了扩展能力，但该系统还存在一些问题：
存储侧扩展灵活性差，扩展成本较高：计算侧通常是无状态计算节点，扩展相对灵活。但存储侧的扩展需要进行数据复制迁移，扩展周期长且灵活性差。同时 MySQL 的分库分表每次扩展需要双倍资源，成本也较高。
单一存储系统，提供的能力有限：MySQL 作为关系模型数据库，在业务模型抽象上提供极强的抽象能力，所以可以说是一个万能存储。在互联网早期应用负载不高的情况下，MySQL 是最优选择，且已经拥有了成熟的扩展方案。但是随着应用场景和负载不断变化，MySQL 还是难以承载。
存储成本高：简单来说，关系数据库是结构化数据存储单位成本最高的存储系统。
如何解决存储侧扩展问题
MySQL 不是万能的，但 MySQL 对应用系统来说是不可替换的，到目前为止都是这样。虽然现在有更多新的云原生关系数据库出现来取代传统 MySQL 的位置，但本质上都脱不了 MySQL 这个壳，只是更强大的 MySQL 而已。所以很多解决方案都是围绕 MySQL 作为辅助方案而不是替换方案出现，比如说 Memcached/Redis 这类缓存系统，帮助 MySQL 抵御大部分查询流量，来解决 MySQL 容易被查询打崩的问题。这个设计思想是『分而治之』，将原本 MySQL 所承担的职责进行细分，能分离解决的就分离解决。现代数据架构就是基于此思路，仍然以 MySQL 作为应用交互和业务数据存储的核心，但是使用一些辅助方案解决 MySQL 的问题。
