您查看的文章来源于http://www.oklinux.cn
前言:
网站在Web 2.0时代，时常面临迅速增加的访问量（这是好事情），但是我们的应用如何满足用户的访问需求，而且基本上我们看到的情况都是性能瓶颈都是在数据库上，这 个不怪数据库，毕竟要满足很大访问量确实对于任何一款数据库都是很大的压力，不论是商业数据库Oracle、MS SQL Server、DB2之类，还是开源的MySQL、PostgreSQL，都是很大的挑战，解决的方法很简单，就是把数据分散在不同的数据库上（可以是硬 件上的，也可以是逻辑上的），本文就是主要讨论数据库分散存储的的问题。
目前主要分布存储的方式都是按照一定的方式进行切分，主要是垂直切分（纵向）和水平切分（横向）两种方式，当然，也有两种结合的方式，达到更到的切分粒度。
◆1. 垂直切分（纵向）数据是数据库切分按照网站业务、产品进行切分，比如用户数据、博客文章数据、照片数据、标签数据、群组数据等等每个业务一个独立的数据库或者数据库服务器。
◆2. 水平切分（横向）数据是把所有数据当作一个大产品，但是把所有的平面数据按照某些Key（比如用户名）分散在不同数据库或者数据库服务器上，分散对数据访问的压力，这种方式也是本文主要要探讨的。
本文主要针对的的 MySQL/PostgreSQL 类的开源数据库，同时平台是在 Linux/FreeBSD，使用 PHP/Perl/Ruby/Python 等脚本语言，搭配 Apache/Lighttpd 等Web服务器 的平台下面的Web应用，不讨论静态文件的存储，比如视频、图片、CSS、JS，那是另外一个话题。
说明：下面将会反复提到的一个名次“节点”（Node），指的是一个数据库节点，可能是物理的一台数据库服务器，也可能是一个数据库，一般情况是指一台数据库服务器，并且是具有 Master/Slave 结构的数据库服务器，我们查看一下图片，了解这样节点的架构：
（图1）
一、基于散列的分布方式
1.散列方式介绍
基 于散列（Hash）的分布存储方式，主要是依赖主要Key和散列算法，比如以用户为主的应用主要的角色就是用户，那么做Key的就可以是用户ID或者是用 户名、邮件地址之类（该值必须在站点中随处传递），使用这个唯一值作为Key，通过对这个Key进行散列算法，把不同的用户数据分散在不同的数据库节点 （Node）上。
我们通过简单的实例来描述这个问题：比如有一个应用，Key是用户ID，拥有10个数据库节点，最简单的散列算法是我们 用户ID数模以我们所有节点数，余数就是对应的节点机器，算法：所在节点 = 用户ID % 总节点数，那么，用户ID为125的用户所在节点：125 % 10 = 5，那么应该在名字为5的节点上。同样的，可以构造更为强大合理的Hash算法来更均匀的分配用户到不同的节点上。
我们查看一下采用散列分布方式的数据结构图：
（图2）
2.散列分布存储方式的扩容
我们知道既然定义了一个散列算法，那么这些Key就会按部就班的分散到指定节点上，但是如果目前的所有节点不够满足要求怎么办？这就存在一个扩容的问题，扩容首当其冲的就是要修改散列算法，同时数据也要根据散列算法进修迁移或者修改。
(1) 迁移方式扩容：修 改散列算法以后，比如之前是10个节点，现在增加到20个节点，那么Hash算法就是[模20]，相应的存在一个以前的节点被分配的数据会比较多，但是新 加入的节点数据少的不平衡的状态，那么可以考虑使用把以前数据中的数据按照Key使用新的Hash算法进行运算出新节点，把数据迁移到新节点，缺点但是这 个成本相应比较大，不稳定性增加；好处是数据比较均匀，并且能够充分利用新旧节点。
(2) 充分利用新节点：增 加新节点以后，Hash算法把新加入的数据全部Hash到新节点上，不再往旧节点上分配数据，这样不存在迁移数据的成本。优点是只需要修改Hash算法， 无须迁移数据就能够简单的增加节点，但是在查询数据的时候，必须使用考虑到旧Key使用旧Hash算法，新增加的Key使用新的Hash算法，不然无法查 找到数据所在节点。缺点很明显，一个是Hash算法复杂度增加，如果频繁的增加新节点，算法将非常复杂，无法维护，另外一个方面是旧节点无法充分利用资源 了，因为旧节点只是单纯的保留旧Key数据，当然了，这个也有合适的解决方案。
总结来说，散列方式分布数据，要新增节点比较困难和繁琐，但是也有很多适合的场合，特别适合能够预计到未来数据量大小的应用，但是普遍 Web2.0 网站都无法预计到数据量。
二、基于全局节点分配方式
1. 全局节点分配方式介绍
就是把所有Key信息与数据库节点之间的映射关系记录下来，保存到全局表中，当需要访问某个节点的时候，首先去全局表中查找，找到以后再定位到相应节点。全局表的存储方式一般两种：
