MDA/MDD/TDD/DDD/DDDDDDD
posts - 536, comments - 111, trackbacks - 0, articles - 0
  BlogJava :: 首页 :: 新随笔 :: 联系 :: 聚合  :: 管理

数据库拆分

Posted on 2010-12-12 00:55 leekiang 阅读(664) 评论(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网站高性能可伸缩架构技术探秘

又拍网架构中的分库设计

只有注册用户登录后才能发表评论。


网站导航: