前两天团队的兄弟问数据库的划分问题，研究了一下，查资料再总结一下。
原来垂直划分是按功能，把表不同字段或部分，拆到不同的服务器（或集群）
水平划分是表结构不变，行内容拆分，现在的key-value看起来更像是水平。
之前的理解基本上正确，查资料进一步深化。
这是一个对比图
|
Horizontal |
Vertical |
|
Limitation with high d (max columns). |
No problems with high d. |
|
Default layout for most algorithms. |
Requires clustered index. |
|
SQL arithmetic expressions and UDFs. |
SQL aggregations, joins, UDFs. |
|
Easy to interpret. |
Difficult to interpret. |
|
Suitable for dense matrices. |
Suitable for sparse matrices. |
|
Complete record processing |
UDF: detect point boundaries |
|
n rows, d columns |
dn rows, few (3 or 4) columns |
|
Fast n I/Os |
Slow dn I/Os (n I/Os clustered) |
下面是文章，原文后的讨论也不错，值得一看：
＝＝＝＝＝＝＝＝＝＝
数据库的水平划分和垂直划分很早以前就接触了，只是没有实践，没有什么体会，只有最近两年才有接触，今天也和大家聊聊。
垂直划分
按照功能划分，把数据分别放到不同的数据库和服务器。
当一个网站开始刚刚创建时，可能只是考虑一天只有几十或者几百个人访问，数据库可能就个db，所有表都放一起，一台普通的服务器可能就够了，而且开发人员也非常高兴，而且信心十足，因为所有的表都在一个库中，这样查询语句就可以随便关联了，多美的一件事情。但是随着访问压力的增加，读写操作不断增加，数据库的压力绝对越来越大，可能接近极限，这时可能人们想到增加从服务器，做什么集群之类的，可是问题又来了，数据量也快速增长。
这时可以考虑对读写操作进行分离，按照业务把不同的数据放到不同的库中。其实在一个大型而且臃肿的数据库中表和表之间的数据很多是没有关系的，或者更加不需要（join）操作，理论上就应该把他们分别放到不同的服务器。例如用户的收藏夹的数据和博客的数据库就可以放到两个独立的服务器。这个就叫垂直划分（其实叫什么不重要）。
当博客或者收藏夹的数据不断增加后，应该怎么办，这样就引出了另外一个做法，叫水平划分。
水平划分
则把一个表的数据划分到不同的数据库，两个数据库的表结构一样。怎么划分，应该根据一定的规则，可以根据数据的产生者来做引导，上面的数据是由人产生的，可以根据人的id来划分数据库。然后再根据一定的规则，先获知数据在哪个数据库。
其实很多大型网站都经历了数据库垂直划分和水平的划分的阶段。其实这个可以根据经验来确定，不一定由某些硬性的规则。
以刚才的博客为例，数据可以根据userid的奇偶来确定数据的划分。把id为基数的放到A库，为偶数的放B库。
这样通过userId就可以知道用户的博客的数据在哪个数据库。其实可以根据userId%10来处理。还可以根据著名的HASH算法来处理。
当初看手机之家的架构是发现他们是：
水平切分：对数据进行水平分割。
a.最好分到同一个数据库。
b.一种已经证明是切实可行的方案：主表＋辅表。
c.有3种类型：主表不打散、主表打散无辅表、主表打散有辅表。
d.但对程序员来说，TA看到的只是一张表，不妨称之为虚表(逻辑表)? ，这张虚表实际上可能是由N张实表(物理表)组成的。
哈哈，我还是喜欢把数据分到不同的数据库，这个可以按照业务来和环境来定吧。
在说句题外话，如果是大型数据库，还可以做读写分离等。
=========
转自：http://liriguang.javaeye.com/blog/625309
