作者：lirig
出处：http://liriguang.iteye.com/blog/625309
数据库的水平划分和垂直划分很早以前就接触了，只是没有实践，没有什么体会，只有最近两年才有接触，今天也和大家聊聊。
垂直划分
按照功能划分，把数据分别放到不同的数据库和服务器。
当一个网站开始刚刚创建时，可能只是考虑一天只有几十或者几百个人访问，数据库可能就个db，所有表都放一起，一台普通的服务器可能就够了，而且开发人员也非常高兴，而且信心十足，因为所有的表都在一个库中，这样查询语句就可以随便关联了，多美的一件事情。但是随着访问压力的增加，读写操作不断增加，数据库的压力绝对越来越大，可能接近极限，这时可能人们想到增加从服务器，做什么集群之类的，可是问题又来了，数据量也快速增长。
这时可以考虑对读写操作进行分离，按照业务把不同的数据放到不同的库中。其实在一个大型而且臃肿的数据库中表和表之间的数据很多是没有关系的，或者更加不需要（join）操作，理论上就应该把他们分别放到不同的服务器。例如用户的收藏夹的数据和博客的数据库就可以放到两个独立的服务器。这个就叫垂直划分（其实叫什么不重要）。
当博客或者收藏夹的数据不断增加后，应该怎么办，这样就引出了另外一个做法，叫水平划分。
水平划分
则把一个表的数据划分到不同的数据库，两个数据库的表结构一样。怎么划分，应该根据一定的规则，可以根据数据的产生者来做引导，上面的数据是由人产生的，可以根据人的id来划分数据库。然后再根据一定的规则，先获知数据在哪个数据库。
其实很多大型网站都经历了数据库垂直划分和水平的划分的阶段。其实这个可以根据经验来确定，不一定由某些硬性的规则。
以刚才的博客为例，数据可以根据userid的奇偶来确定数据的划分。把id为基数的放到A库，为偶数的放B库。
这样通过userId就可以知道用户的博客的数据在哪个数据库。其实可以根据userId%10来处理。还可以根据著名的HASH算法来处理。
当初看手机之家的架构是发现他们是：
水平切分：对数据进行水平分割。
a.最好分到同一个数据库。
b.一种已经证明是切实可行的方案：主表＋辅表。
c.有3种类型：主表不打散、主表打散无辅表、主表打散有辅表。
d.但对程序员来说，TA看到的只是一张表，不妨称之为虚表(逻辑表)? ，这张虚表实际上可能是由N张实表(物理表)组成的。
哈哈，我还是喜欢把数据分到不同的数据库，这个可以按照业务来和环境来定吧。
在说句题外话，如果是大型数据库，还可以做读写分离等。
顶
踩
评论
垂直分库：按照业务垂直划分。比如：可以按照业务分为资金、会员、订单三个数据库。需要解决的问题：跨数据库的事务、jion查询等问题。
水平分库：按照规则划分，一般水平分库是在垂直分库之后的。比如每天处理的订单数量是海量的，可以按照一定的规则水平划分。需要解决的问题：数据路由、组装。
读写分离：对于时效性不高的数据，可以通过读写分离缓解数据库压力。需要解决的问题：在业务上区分哪些业务上是允许一定时间延迟的，以及数据同步问题。
我首先想问下 当垂直划分的时候 我的订单数据里面关联了会员信息，当页面要显示会员信息该怎么办？ 我是应该在订单数据库里面做数据冗余还是关联查询，或者还有其他什么更好的方式呢？
不会关联查询，一般会员信息会写到缓存中。或者一次性查询多个
垂直分库：按照业务垂直划分。比如：可以按照业务分为资金、会员、订单三个数据库。需要解决的问题：跨数据库的事务、jion查询等问题。
水平分库：按照规则划分，一般水平分库是在垂直分库之后的。比如每天处理的订单数量是海量的，可以按照一定的规则水平划分。需要解决的问题：数据路由、组装。
读写分离：对于时效性不高的数据，可以通过读写分离缓解数据库压力。需要解决的问题：在业务上区分哪些业务上是允许一定时间延迟的，以及数据同步问题。
我首先想问下 当垂直划分的时候 我的订单数据里面关联了会员信息，当页面要显示会员信息该怎么办？ 我是应该在订单数据库里面做数据冗余还是关联查询，或者还有其他什么更好的方式呢？
垂直分库：按照业务垂直划分。比如：可以按照业务分为资金、会员、订单三个数据库。需要解决的问题：跨数据库的事务、jion查询等问题。
水平分库：按照规则划分，一般水平分库是在垂直分库之后的。比如每天处理的订单数量是海量的，可以按照一定的规则水平划分。需要解决的问题：数据路由、组装。
读写分离：对于时效性不高的数据，可以通过读写分离缓解数据库压力。需要解决的问题：在业务上区分哪些业务上是允许一定时间延迟的，以及数据同步问题。
很多应用 刚开始几年没人关心报表 后来提出来的概率还是挺大的
这种情况一般 要用到专门的report DB
数据由后台job 异步生产
分区类似，分区是数据库实现的，技术性的。水平分库是策略性的。
以减少数据量，是这样吧。
分到不同的库感觉没什么必要
有必要，数据库可放置在不同的存储媒介，这样，单点的IO就减少了。
分页查找。类似这种客户总数的统计信息一致性要求不是那个强，因此可以离线查询或者单独保存。
水平划分的数据的规则要根据客户来划分。可以邮件或者QQ我：814562275
以减少数据量，是这样吧。
分到不同的库感觉没什么必要
应该是这样的：一个业务数据库中其中有些表的数据到达几十个亿后，而且每天访问压力也过大，这样就把原来的数据根据一定的规则分成两个或者多个库，表结构一样，很明确，访问压力从原来的一个库变成几个库，这样也减轻了。而且是多个服务器，io也减少了。
以减少数据量，是这样吧。
分到不同的库感觉没什么必要