淘宝的数据拆分历程

摘自:
http://blog.csdn.net/imcxin/article/details/7298757
淘宝的数据拆分历程

系统刚开始的时候，用户数量不多，所有的数据都放在了同一个数据库中，此时因为用户少压力小，一个数据库完全可以应付的了。但是随着用户数量不断增加，数据库压力也与日俱增，它终于在某一天大家都和惬意的时候挂掉啦。此时是到了读写分离的时候，这个时候我们会配置一个server为master节点，然后配几个salve节点，这样以来通过读写分离，使得读取数据的压力分摊到了不同的salve节点上面，系统终于又恢复了正常，开始正常运行了。但是好景还是不长，有一天我们发现master撑不住了，负载很高，随时都有挂掉的风险，这个时候就需要进行垂直拆分啦（也就是所谓的分库），比如将商品信息、用户信息、交易信息分别存储到不同的数据库中，同时还可以针对商品信息的库采用master/salve模式，OK， 通过分库以后，各个按照功能拆分的数据库写压力被分担到了不同的server上面，这样数据库的压力终于有恢复到正常状态。但是不是这样，我们就可以高枕无忧了呢？NO,通过前辈们的经验总结显示，随着用户量的不断增加，你会发现系统中的某些数据表会变的异常庞大，比如好友关系表，店铺的参数配置表等，此时无论论是写入还是读取这些表的数据，对数据库来说都是一个很耗费精力的事情，因此此时就需要我们进行“水平拆分”了（这就是俗话说的分表，或者说sharding）。
上面的阐述，无非就是告诉大家一个事实“数据库是系统中最不容易scale out的一层”，一个大型的互联网应用必然会经过一个从单一DB server, 到Master/salve, 再到垂直分区（分库），然后再到水平分区（分表即sharding）的过程，而在这个过程中，Master/salve 以及垂直分区相对比较容易，对应用的影响也不是很大，但是分表会引起一些棘手的问题，比如不能跨越多个分区join查询数据，如何平衡各个shards的负载等等，这个时候就需要一个通用的DAL框架来屏蔽底层数据存储对应用逻辑的影响，使得底层数据的访问对应用透明化。
拿淘宝目前的情况来说，淘宝目前也正在从昂贵的高端存储（小型机+ORACLE）切换到MYSQL, 切换到MYSQL以后，势必会遇到垂直分区（分库）以及水平分区（Sharding）的问题，因此目前淘宝根据自己的业务特点也开发了自己的TDDL框架，此框架主要解决了分库分表对应用的透明化以及异构数据库之间的数据复制问题。