转自： http://blog.csdn.net/wzht82/archive/2007/08/30/1765503.aspx

1      
背景
我们知道数据是一个公司的命脉，随着业务越做越大，数据量也会越来越大，计算也会越来越复杂，性能，可靠性，可扩展性的需求就会越来越强烈，这个时候一个集中式的数据库显然已经满足不了需求了。对于技术决策者来说有两条路可以走，第一：按照现有的大型数据库的解决方案，比如SQL
SERVER Cluster或者Oracle RAC等,但是这也就等于走上了一条烧钱的道路，小则几十万，大则上百万乃至更多；第二：使用真正能够扩展的分布式数据库，利用中小型服务器甚至是PC机的累加来替代大型的服务器，这也是很多公司希望的，却苦于没有合适产品，现在有了ClusterKiller，用它真正能给您带来：      
高性能，高可用性，高扩展性，高性价比。
http://www.mediafire.com/?bd0bdjm2gxh
介绍的录像版本
http://www.mediafire.com/?0tygenydtdg
demo的录像版本
http://www.mediafire.com/?bhfalz09i4e 试用版
2      
方案比较
2.1    SQL SERVER的集群模式


这种结构只能说是一种故障转移的机制，当有一个节点出现问题后把负载转移到另一个节点上。在负载能力上和扩展性上没有任何办法，而且还浪费了硬件资源
2.2    Oracle Real Application Clusters
(RAC)

Oracle Rac最多可支持64个节点，基本上算是解决了性能，扩展性的问题了，但是它在存储上还是一个单点，且不说出现故障怎么办，IO也可能会成为性能瓶颈。 我们都知道一个数据库大到一定程度的时候，在物理上分区才能从根本上解决问题，对几十万数据进行查找和几百万上千万的数据进行查找在系统的消耗上以及响应时间上有着几何级的降低。
2.3    Cluster Killer
 
 
从图例中可以看出，下面的像网格一样的机器叫数据层，每个机器上存储着数据全集的一个分区，每一行组成一个数据全集，每一列是某个分区的多份相同的数据从而达到查询时负载均衡的效果，同时也是高可用性的保障：某个列的机器出现问题后其他的机器会负载访问。为了不让这样一个复杂的结构暴露给应用程序，在数据层上面又放了一层机器叫中间层，中间层机器的数据库中驻留着的中间件来处理SQL语句，根据SQL语句的类型和条件来决定由哪些机器来提供服务。在中间层的外面加一个负载均衡设备， 这样应用程序或者开发/维护的人员通过负载均衡设备连接到中间层的任意一台机器上操作，感觉就像还在使用原来的一个数据库那样，易用性非常好。以下从各个角度具体的说明一下：
l        
开发：中间件是宿主在数据库中的，所以面对数据库写SQL语句的方式没有改变，只需要把SQL语句从语法的角度上封装一下即可。还是利用原有的数据库的管理工具，不需要使用的新的管理工具，不需要改变原有的使用习惯，不需要学习新的知识。
l        
数据库维护：对于维护表，存储过程，安全等数据库对象还是像使用一个数据库那样在中间层的任意一台机器上执行，中间件会抓取到更改并分发到其他的机器上。不会增加额外的工作量。
l        
机器维护：因为这个结构比集中式的结构在机器的数量上要增加了很多，所以在机器层面上的维护成本比以前要有所增加。不过对于机器的维护不会影响整个结构的可用性，只需要在中间层的任意一台机器上更改一下配置就可以把某台机器添加到结构中或从结构中移出。
l        
诊断：当出现异常后会明确的指定出错原因以及出错的机器，另外还有执行日志详细的记录每个执行步骤的细节。
l        
分区：支持多种数据类型的分区，分区方式有静态分区和线形增长两种方式。静态分区不言而喻就是一开始就要规划好分区的个数；线形增长方式就是一开始只有一个或少数几个分区列，随着数据量和访问的增长的时候再添加新的分区从而达到了线性扩展的效果
l        
总结：中间件的定位和作用是只是把很多的数据库服务器联合起来最终实现高扩展性，高可用性以及高性能。许多关键的数据库技术比如事务，连接池，锁，安全等还是依靠数据库来完成，无论从研发成本还是实施的风险都降到最低。
 
2.4    指标比较
l        
故障转移/可靠性
n        
SQL SERVER Cluster：能做到前面的计算节点的故障转移，后面的存储设备还是单点
n        
Oracle RAC：能做到前面的计算节点的故障转移，后面的存储设备还是单点
n        
Cluster Killer：从每个维度上都是可扩展的，所以无论从哪个维度上的机器损坏以后都能找到替代者从而实现故障转移。
l        
负载均衡
n        
SQL SERVER Cluster：从它的工作机制上可以看出它的两个节点只能有一个处于工作状态，所以没有负载均衡能力
n        
Oracle RAC：它前面的几个计算节点是可以同时提供服务的，但是后面的存储设备只有一个。所以说是计算能够均载，存储不能均载
n        
Cluster Killer：即能够计算均载也能存储均载
l        
扩展性
n        
SQL SERVER Cluster：只能够两个计算节点带一个存储组成
n        
Oracle RAC：最多64个节点带一个存储组成
n        
Cluster Killer：每个维度上都能扩展，而且能够根据数据的增加线形扩展，最小用两台机器就可以搭建起来，另外每个机器之间的关系是松散耦合的，扩展起来不需要复杂的安装，配置。
l        
硬件要求
n        
SQL SERVER Cluster：因为要使用能够连接存储设备的服务器，而这类服务器的配置都很高，都是中高档服务器，价格不菲。而且还有一个节点在正常情况下是闲置的，所以性价比低
n        
Oracle RAC：它的硬件配置要求同上，但是起码没有闲置的资源，性价比中
n        
Cluster Killer：不需要每个机器的紧密耦合，对机器的配置没有要求，用买一个集群的钱可以买几十台小型服务器或者上百台的PC机，Google的分布式结构已经验证了它的高性价比。
 
3      
成功案例
3.1    某大型求职/招聘网站
l        
项目背景：给企业方使用的一个搜索个人简历的系统，特点是数据量大，查询条件复杂，更新频繁。具体数据为：简历主表700万，子表从1600万到2000万不等；每天查询12万次，40%的查询条件中带有关键词；个人用户每天新增/更新简历的事务数为120万次。
l        
解决方案：使用30台DELL 2950小型PC服务器搭建起分布式数据库结构。
l        
性能测试数据：
n        
测试模型：查询
n        
查询条件：大于等于线上用户的实际条件
n        
测试工具：LoadRunner8.0
n        
测试时间：20小时
n        
并发数：50
n        
响应时间：平均1.5秒，90%的响应时间在1.9秒以下，方差：1.1
n        
查询次数：成功487325，超时：98，没有其它类型错误
l        
收益：
n        
因为组件不会影响业务逻辑，所以业务程序不用重构，只用2天就升级到新的架构上
n        
查询时间从原来的10秒缩减到不到1秒，92%的查询在秒以下，大大提高客户体验
n        
真正的7*24的持续提供服务
n        
系统的扩展能力大大增强，使得客户有能力上原来不能上的更复杂的业务逻辑，建立更好的搜索模型，从而提升了客户在行业内的竞争实力。

Trackback:
http://tb.blog.csdn.net/TrackBack.aspx?PostId=1765503

[http://wz.csdn.net/storeit.aspx?t='+escape(d.title)+'&u='+escape(d.location.href)+'&c='+escape(t),'keyit','scrollbars=no,width=590,height=300,left=75,top=20,status=no,resizable=yes'));saveit.focus();" target="_blank">收藏到我的网摘]  
[发送Trackback]  wzht82发表于
2007年08月30日 15:35:00 -->

特别推荐：
想在这里投放广告？点击查看详情
你的未来？你决定--
要么是一名网络工程师， 要么是一个不做恶的黑客。 microsoft
你离编程高手还有多远？
聪明的程序员知道在高手那学经验走捷径 看技术图书，就上CSDN读书频道 microsoft
潘爱民：只有看了此书才能真正认识C++
聪明的程序员知道在高手那学经验走捷径 microsoft
贝尔实验室上课用的C语言教材
有代码实例 看技术图书，就上CSDN读书频道 microsoft
世界顶级编程专家为你专讲C++编程艺术
聪明的程序员知道在高手那学经验走捷径 microsoft

 |

评论
#  过客 发表于2007-08-30
16:50:36  IP: 218.247.166.*
看了你的文章，觉得不错，很有远见，我公司正为这事情烦恼呢
希望试用

#  Sakuya 发表于2007-08-31
16:56:37  IP: 202.96.53.*
不知道有没有做过压力测试，压力测试的水平如何。希望能给出更加具体的测试报告。比如说：
1.
当时硬件配置，包括磁盘速度
2. workload的特点， 例如查询种类，分别对于select, insert &
update的性能表现
3. 支持的最大对于中间层的并发用户数
4.
对于数据库损毁的修复方法

希望能提供获取试用版本的方法

#  wzht82 发表于2007-09-03
12:31:25  IP: 218.249.14.*
谢谢非常专业的问题，回答如下：
1.正文中提到的第一个案例的机器统一是DELL
2950服务器，基本硬件配置是英特尔至强5300系列(Clovertown)四核处理器，4GB内存，140GBSCSI
(SAS)硬盘，15000转，更详细配置信息请见http://www1.ap.dell.com/content/products/productdetails.aspx/pedge_2950?c=cn&l=zh&s=bsd&cs=cnbsd1

2.承载业务的特点是：是企业用户查询个人简历，数据量大，查询复杂，40%多查询中带有关键词。
另外个人用户更新/刷新自己的简历频繁，具体数字正文中有介绍

3.压力测试的数据我以及补充在正文中了

4.中间层的支持的最大并发数理论上是没有限制的，因为无论是中间层还是数据层的各个维度上都是可以扩展的。

5.数据库的修复方法：因为每个层次都是多点的，
任何一个机器坏了修好后都能找到和他发挥同样作用的并且是好的机器，从它上面同步过来数据后即可上线提供服务

#  xinyou 发表于2007-09-04
14:16:14  IP: 210.83.202.*
负载均衡设备坏了咋办呀？

#  wzht82 发表于2007-09-04 16:01:02  IP:
218.249.14.*
是这样，我们做解决方案为了高可用性都不应该有单点出现，市场的负载均衡本身也是可以负载均衡的，比如F5

#  wacle 发表于2007-09-05
10:14:23  IP: 207.46.55.*
我只看到了你的查询，没看到你对DML操作是如何进行高效率同步的？如果仅仅用于查询,
直接windows server 2003 cluster+负载均衡就可以了，SQL Server全装成default
instance.
数据同步才是最关键的东西。

#  wzht82 发表于2007-09-05 11:33:33  IP:
211.151.251.*
当然如你所说如果仅支持查询那确实就没什么意思了，这个结构是支持insert/update/delete/truncate等语句的。
你还是执行一个像在原来的数据库那样执行一个sql语句比如insert dbo.Table1 VALUES(1, @Value1,
GETDATE())，中间层数据库中的中间件就会截获到这个语句并分析这个语句，根据这个表的分区字段以及要插入的值找出应该把这个语句插入到哪个分区中，这个分区有多少台机器在做均载，那么就会并发的同时插入到这些机器中去。同理其他的语句。
所有的这一切的实现都是隐藏的，你还像使用一个数据库那样提交语句就可以了。这文章中提到的成功案例里面提过每天有120万次的更新， 但是对于这个结构来说太小儿科了，
平均的响应时间是5毫秒。

#  王继锋 发表于2007-10-09
09:12:45  IP: 221.221.148.*
太复杂了，看不懂

#  Kakrat 发表于2007-10-17
19:21:40  IP: 222.129.27.*
负载均衡设备具体起什么作用? 客户端直接和中间层打交道还是通过负载均衡设备?
如果通过负载均衡设备, 那它不就成了瓶颈点了?

另外,
底层的数据库engine用的是什么?

#  wzht82 发表于2007-10-17
20:22:46  IP: 218.249.14.*
从图中看到，如果访问量非常大，计算非常频繁， 那么中间层可以是可以扩展的，
不可能也不必要让应用程序知道这个结构，所以要应用程序通过负载均衡器来连接到中间层数据库。 负载均衡有硬件设备的，也有软件实现的，
首先它只是负责把应用程序的请求转向一下对性能的消耗不是很大，一般的只需要几个就能支撑起一个大型网站的应用了。其次是负载均衡器也可以自己再做负载/故障转移来避免单点，这就不在我们的讨论范围内了。

另外：这个中间件是宿主在现有的数据库上的，
不需要改变数据库，也不需要改变业务逻辑，最终还是给您一个数据库的感觉。

如果您有时间可以看看那两个视频文件，相信您会有更直接的认识