随着一个网站的业务不断扩展,数据不断增加,数据库的压力也会越来越大,对数据库或者SQL的基本优化可能达不到最终的效果,我们可以采用读写分离的策略来改变现状。读写分离现在被大量应用于很多大型网站,这个技术也不足为奇了。ebay就做得非常好。ebay用的是oracle,听说是用Quest Share Plex 来实现主从复制数据。
读写分离简单的说是把对数据库读和写的操作分开对应不同的数据库服务器,这样能有效地减轻数据库压力,也能减轻io压力。主数据库提供写操作,从数据库提供读操作,其实在很多系统中,主要是读的操作。当主数据库进行写操作时,数据要同步到从的数据库,这样才能有效保证数据库完整性。Quest SharePlex就是比较牛的同步数据工具,听说比oracle本身的流复制还好,mysql也有自己的同步数据技术。mysql只要是通过二进制日志来复制数据。通过日志在从数据库重复主数据库的操作达到复制数据目的。这个复制比较好的就是通过异步方法,把数据同步到从数据库。
主数据库同步到从数据库后,从数据库一般由多台数据库组成这样才能达到减轻压力的目的。读的操作怎么样分配到从数据库上?应该根据服务器的压力把读的操作分配到服务器,而不是简单的随机分配。mysql提供了MySQL-Proxy实现读写分离操作。不过MySQL-Proxy好像很久不更新了。oracle可以通过F5有效分配读从数据库的压力。
ebay的读写分离(网上找到就拿来用了)
mysql的读写分离 上面说的数据库同步复制,都是在从同一种数据库中,如果我要把oracle的数据同步到mysql中,其实要实现这种方案的理由很简单,mysql免费,oracle太贵。好像Quest SharePlex也实现不了改功能吧。好像现在市面还没有这个工具吧。那样应该怎么实现数据同步?其实我们可以考虑自己开发一套同步数据组件,通过消息,实现异步复制数据。其实这个实现起来要考虑很多方面问题,高并发的问题,失败记录等。其实这种方法也可以同步数据到memcache中。听说oracle的Stream也能实现,不过没有试过。
---------------------华丽的分割线--------------------------------------------------------------
垂直分库、水平分表
数据库的水平划分和垂直划分很早以前就接触了,只是没有实践,没有什么体会,只有最近两年才有接触,今天也和大家聊聊。
垂直划分
按照功能划分,把数据分别放到不同的数据库和服务器。
当一个网站开始刚刚创建时,可能只是考虑一天只有几十或者几百个人访问,数据库可能就个db,所有表都放一起,一台普通的服务器可能就够了,而且开发人员也非常高兴,而且信心十足,因为所有的表都在一个库中,这样查询语句就可以随便关联了,多美的一件事情。但是随着访问压力的增加,读写操作不断增加,数据库的压力绝对越来越大,可能接近极限,这时可能人们想到增加从服务器,做什么集群之类的,可是问题又来了,数据量也快速增长。
这时可以考虑对读写操作进行分离,按照业务把不同的数据放到不同的库中。其实在一个大型而且臃肿的数据库中表和表之间的数据很多是没有关系的,或者更加不需要(join)操作,理论上就应该把他们分别放到不同的服务器。例如用户的收藏夹的数据和博客的数据库就可以放到两个独立的服务器。这个就叫垂直划分(其实叫什么不重要)。
当博客或者收藏夹的数据不断增加后,应该怎么办,这样就引出了另外一个做法,叫水平划分。
水平划分
则把一个表的数据划分到不同的数据库,两个数据库的表结构一样。怎么划分,应该根据一定的规则,可以根据数据的产生者来做引导,上面的数据是由人产生的,可以根据人的id来划分数据库。然后再根据一定的规则,先获知数据在哪个数据库。
其实很多大型网站都经历了数据库垂直划分和水平的划分的阶段。其实这个可以根据经验来确定,不一定由某些硬性的规则。
以刚才的博客为例,数据可以根据userid的奇偶来确定数据的划分。把id为基数的放到A库,为偶数的放B库。
这样通过userId就可以知道用户的博客的数据在哪个数据库。其实可以根据userId%10来处理。还可以根据著名的HASH算法来处理。
当初看手机之家的架构是发现他们是:
水平切分:对数据进行水平分割。
a.最好分到同一个数据库。
b.一种已经证明是切实可行的方案:主表+辅表。
c.有3种类型:主表不打散、主表打散无辅表、主表打散有辅表。
d.但对程序员来说,TA看到的只是一张表,不妨称之为虚表(逻辑表)? ,这张虚表实际上可能是由N张实表(物理表)组成的。
哈哈,我还是喜欢把数据分到不同的数据库,这个可以按照业务来和环境来定吧。
在说句题外话,如果是大型数据库,还可以做读写分离等。
找不到转载来源,暂时留空。。