0个节点，那么设定每个节点被分配的数据的概率为10，我们查看数据表结构：
 
       NodeID Weight
1      10
2      10
3      10
现在新加入了一个 节点，新加入的节点，被分配Key的几率要大于旧节点，那么就必须对这个新加入的节点进行概率计算，计算公式：10х+у=100, у>х，得出：у{10...90}，х{1...9}，x是单个旧节点的概率，旧节点的每个节点的概率是一样的，y是新节点的概率，按照这个计算 公式，推算出新节点y的概率的范围，具体按照具体不同应用的概率公式进行计算。
 
 
 
 
三、存在的问题
 
现在我们来分析和解决一下我们上面两种分布存储方式的存在的问题，便于在实际考虑架构的时候能够避免或者是融合一些问题和缺点。
 
1. 散列和全局分配方式都存在问题
 
(1) 散列方式扩容不是很方便，必须修改散列算法，同时可能还需要对数据进行迁移，它的优点是从Key定位一个节点非常快，O(1)的时间复杂度，而且基本不需要查询数据库，节约响应时间。
(2) 全局分配方式存在的问题最明显的是单点故障，全局数据库down掉将影响所有应用。另外一个问题是查询量大，对每个Key节点的操作都必须经过全局数据库，压力很大，优点是扩容方便，增加节点简单。
 
 
2. 分布存储带来的搜索和统计问题
 
(1) 一般搜索或统计都是对所有数据进行处理，但因为拆分以后，数据分散在不同节点机器上，无法进行全局查找和统计。解决方案一是对主要的基础数据存储在全局表中，便于查找和统计，但这类数据不宜太多，部分核心数据。
(2) 采用站内搜索引擎来索引和记录全部数据，比如采用 Lucene 等开源索引系统进行所有数据的索引，便于搜索。 对于统计操作可以采用后台非实时统计，可采用遍历所有节点的方式，但效率低下。
 
 
3. 性能优化问题
 
(1) 散列算法，节点概率和分配等为了提高性能都可以使用编译语言开发，做成lib或者是所有php扩展形式。
(2) 对于采用 MySQL 的情况，可以采用自定义的数据库连接池，采用 Apache Module 形式加载，能够自由定制的采用各种连接方式。
(3) 对于全局数据或都频繁访问的数据，可以采用APC、Memcache、DBM、BDB、共享内存、文件系统等各种方式进行缓存，减少数据库的访问压力。
(4) 采用数据本身的强大处理机制，比如 MySQL5 的表分区或者是 MySQL5 的Cluster 。另外建议在实际架构中采用InnoDB表引擎作为主要存储引擎，MyISAM作为一些日志、统计数据等场合，不论在安全、可靠性、速度都有保障。
 
 
 
总结:
 
本文泛泛的分析了在网站项目（特别是Web2.0）中关于数据库分布存储的一些方式方法，基本上上面提到的两种分布方案笔者都经过实验或者是使用过类似成型 的项目，所以在实践性方面是有保障的，至于在具体实施过程中，可以按照具体的应用和项目进行选择性处理，这样，让你的网站速度飞快，用户体验一流。同时本 文有些概念和描述不一定准确，如果有不足之处，请谅解并且提出来，不胜感谢。另外，如果有更好的方案或者更完善的解决方式，非常希望能够分享一下，本文更 希望起到抛砖引玉的作用。