Posted on 2010-12-12 00:55
leekiang 阅读(697)
评论(0) 编辑 收藏 所属分类:
架构设计
在前面“应用拆分”主题中，我们提到了一个大型互联网应用需要进行良好的拆分，而那里我们仅仅说了”应用级别”的拆分，其实我们的互联网应用除了应
用级别的拆分以外，还有另外一个很重要的层面就是存储如何拆分的。因此这个主题主要涉及到如何对存储系统，通常就是所说的RDBMS进行拆分。
确定了这个小节的主题之后，我们回顾一下，一个互联网应用从小变大的过程中遇到的一些问题，通过遇到的问题来引出我们拆分RDBMS的重要性。
系统刚开始的时候，因为系统刚上线，用户不多，那个时候，所有的数据都放在了同一个数据库中，这个时候因为用户少压力小，一个数据库完全可以应付的
了，但是随着运营那些哥们辛苦的呐喊和拼命的推广以后，突然有一天发现，oh,god,用户数量突然变多了起来，随之而来的就是数据库这哥们受不了，它终
于在某一天大家都和惬意的时候挂掉啦。此时，咱们搞技术的哥们，就去看看究竟是啥原因，我们查了查以后，发现原来是数据库读取压力太大了，此时咱们都清楚
是到了读写分离的时候，这个时候我们会配置一个server为master节点，然后配几个salve节点，这样以来通过读写分离，使得读取数据的压力分
摊到了不同的salve节点上面，系统终于又恢复了正常，开始正常运行了。但是好景还是不长，有一天我们发现master这哥们撑不住了，它负载老高了，
汗流浃背，随时都有翘掉的风险，这个时候就需要咱们垂直分区啦（也就是所谓的分库），比如将商品信息，用户信息，交易信息分别存储到不同的数据库中，同时
还可以针对商品信息的库采用master，salve模式，OK，通过分库以后，各个按照功能拆分的数据库写压力被分担到了不同的server上面，这样
数据库的压力终于有恢复到正常状态。但是是不是这样，我们就可以高枕无忧了呢？NO,这个NO，不是我说的，是前辈们通过经验总结出来的，随着用户量的不
断增加，你会发现系统中的某些表会变的异常庞大，比如好友关系表，店铺的参数配置表等，这个时候无论是写入还是读取这些表的数据，对数据库来说都是一个很
耗费精力的事情，因此此时就需要我们进行“水平分区”了（这就是俗话说的分表，或者说sharding）。
上面说了很多，无非就是告诉大家一个事实“数据库是系统中最不容易scale out的一层”，一个大型的互联网应用必然会经过一个从单一DB
server,到Master/salve,再到垂直分区（分库），然后再到水平分区（分表，sharding）的过程，而在这个过程中，Master
/salve
以及垂直分区相对比较容易，对应用的影响也不是很大，但是分表会引起一些棘手的问题，比如不能跨越多个分区join查询数据，如何平衡各个shards的
负载等等，这个时候就需要一个通用的DAL框架来屏蔽底层数据存储对应用逻辑的影响，使得底层数据的访问对应用透明化。
出处:大型B2C网站高性能可伸缩架构技术探秘
又拍网架构中的分库设计