关系型数据库的架构演变

在互联网场景下，关系型数据库常见的性能瓶颈主要有两个

大量的并发读/写操作，导致倒库出现难以承受的负载压力
单表存储数据量过大，导致检索效率低下

数据库读写分离

在系统初期，整体的并发了相对较小，因此一般都是将所有的数据信息存储在单库中进行读/写操作。但是随着用户规模不断提升，单库逐渐力不从心，TPS/QPS越来越低。因此到了这个时候，dba会将数据库设置为读写分离状态（生产环境一般会采用一主一从或者一主多从），Master负责写操作，Slave作为备库，不开放写操作，但是允许读操作，主从之间保持数据同步即可。
读写分离之后，可以大大提升单库无法支撑的负载压力
需要注意的是：如果Master存在TPS存在较高的情况，Master之前最好将同一份数据落到缓存中，以避免高并发情况下，从Slave中获取不到指定数据的情况发生
[MySQL 主从同步延迟的原因及解决办法(https://blog.csdn.net/soar_away/article/details/72615012)

数据垂直分库

读写分离让系统的吞吐量相对于单库来说有了一定的提升，但是只依靠读写分离并不能一劳永逸，随着用户规模攀升，系统瓶颈一定会暴露。
因为，这个阶段Dba会对数据库执行垂直分库，垂直分库就是根据自身业务垂直划分，将表拆分到不同的业务库中。实现分而治之的数据管理和读写操作。

单表数据量一大，读操作会逐渐成为瓶颈
写操作因为是顺序写，所以基本上数据库的写入操作不会因为数据膨胀而成为瓶颈，但是读操作一定会存在上限；
读操作成为瓶颈的时候，就该做水平分库了

数据库水平分库与水平分表

水平分表:将原本冗余在单库中的单个业务表拆分成为n个“逻辑相关”的业务字表(如：tab_000、tab_0001、…..)
水平分库:如果Master的TPS过高，则还可以对垂直分库后的单一业务进行水平化，同水平分表类似。

分库分表操作主要是为了解决：高并发场景下单库的性能瓶颈，并充分利用分布式的威力提升数据库的读/写能力。
假设后续业务表中的数据量又一次达到存储阈值并对性能产生影响时，DBA只需要再次对现有业务库和业务表横向扩容，并迁移数据即可。

Mysql Sharding 和 Mysql Cluster区别

Mysql Cluster只是一个数据库的集群，其优势只是扩展了数据库的并行处理能力，但是其使用成本、维护成本非常高，并且实施起来比较复杂

Mysql sharding 不近提升数据库的并行处理能力，还能够解决因为单表数据量过大所产生的检索瓶颈。

Mysql Cluster前者是集群模式，Mysql sharding是分布式模式。Sharding是当下互联网最好的选择