随着互联网时代的到来，计算机要管理的数据量成指数级别的飞速上涨。而我们完全无法对用户数做出准确的预估，我们的系统所需要支持的用户数很可能在短短的一个月内突然爆发式的增长几千倍，数据也很可能快速的从原来的几百GB飞速上涨到了几百个TB。如果在这爆发的关键时刻，系统不稳定或无法访问，那么对于业务将会是毁灭性的打击。
单库单表
通常刚开始的时候，应用的数据比较少，也不会很复杂，所以应用只有一个数据库，数据库中的表是一张完整的表，这也是我们刚开始接触数据库时的数据库形态。
读写分离
随着业务的发展，数据量与数据访问量不断增长，很多时候应用的主要业务是读多写少的，比如说一些新闻网站，运营在后台上传了一堆新闻之后，所有的用户都会去读取这些新闻资讯，因此数据库面临的读压力远大于写压力，那么这时候在原来数据库Master的基础上增加一个备用数据库Slave，备库和主库存储着相同的数据，但只提供读服务，不提供写服务。以后的写操作以及事务中的读操作就走主库，其它读操作就走备库，这就是所谓的读写分离。
读写分离会直接带来两个问题：
1、数据复制问题，因为最新写入的数据只会存储在主库中，之后想要在备库中读取到新数据就必须要从主库复制过来，这会带来一定的延迟，造成短期的数据不一致性。但这个问题应该也没有什么特别好的办法，主要依赖于数据库提供的数据复制机制，常用的是根据数据库日志binary-log实现数据复制。
2、数据源选择问题，读写分离之后我们都知道写要找主库，读要找备库，但是程序不知道，所以我们在程序中应该根据SQL来判断出是读操作还是写操作，进而正确选择要访问的数据库。
垂直分库
数据量与访问量继续上升时，主库与从库的压力都在变大，这时候可以根据业务特点考虑将数据库垂直拆分，即把数据库中不同的业务单元的数据划分到不同的数据库里面。比如说，还是新闻网站，注册用户的信息与新闻是没有多大关系的，数据库访问压力大时可以尝试把用户信息相关的表放在一个数据库，新闻相关的表放在一个数据库中，这样大大减小了数据库的访问压力。
垂直分库会带来以下问题：
1、ACID（原子性、一致性、隔离性和持久性）被打破，数据分到不同的数据库之后，原来的事务操作将会受很大影响，比如说注册账户的时候需要在用户表和用户信息表中插入一条数据，单机数据库利用事务可以很好地完成这个任务，但是多机将会变得比较麻烦。以下两点也是因为数据库在不同的机子上而导致简单的操作变得复杂，不一一分析了。
2、Join操作困难
3、外键约束受影响
水平分表
经过长时间积累，业务数据量会达到惊人的地步，每张表存放着大量的数据，任何CRUD（创建、更新、读取和删除操作）都变成了一次极其消耗性能的操作，这个时候就会考虑水平分表，把一张表内大量的数据拆分成多张子表，比如说原来一张表中存放50000条数据，水平分成5张表之后，每张表只要存放10000条数据。这种结构可以比较容易的存储和维护海量数据。
水平分表会在垂直分库的基础上带来更多的影响：
1、自增主键会有影响这个影响很明显，分表中如果使用的是自增主键的话，那么就不能产生唯一的ID了，因为逻辑上来说多个分表其实都属于一张表，自增主键无法标识每一条数据。
2、有些单表查询会变成多表比如说count操作，原来是一张表的问题，现在要从多张分表中共同查询才能得到结果。
总结
一开始的时候，由于数据量比较少，数据库最长见的是单库单表的情况。随着业务的发展，业务库中的数据量不断增长。单库的性能已经不能再支持业务的发展。我们开始使用对数据库进行分库分表和读写分离的方式，来分散数据库的压力，提高整体的性能。
同时，原来的单机数据库的容灾性能也不好，当原有的数据库宕机后，应用方便没法正常工作了。所以后续出现了数据库主备的方案，当主库出现问题后，将请求切换到备库，保证数据库服务对外服务的正常工作。
直连单机数据库，还带来了一个运维的问题，当需要切换数据库的时候，这个变动对应用方无法做到透明，需要应用方修改响应的链接参数。为了解决以上问题，并且将这些问题做到对应用的透明化，使得应用方能专注于业务，分布式数据库访问引擎应运而生。
上图中的数据库中间件就是分布式数据库访问引擎，它的作用是将SQL路由到正确的分库、分表中去执行，并将执行结果进行汇总、返回。上层可以像单库单表一样使用数据源，无需知道分布式数据库的细节。
这个数据库中间件主要解决以下两个问题：
1、支持高并发，解决数据的读取和写入瓶颈；
2、数据安全。
解决这两个问题的主要手段是“复制”和“切分”，通过数据复制，一份数据存多个备份，实现宕机的主备切换，解决高并发读瓶颈；通过对数据表的水平切分，将一张大表分成多张子表，解决高并发写瓶颈。