大型分布式数据库应用的案例.docx

大型分布式数据库应用的案例.docx

ID:51702529

大小:117.45 KB

页数:4页

时间:2020-03-15

大型分布式数据库应用的案例.docx_第1页
大型分布式数据库应用的案例.docx_第2页
大型分布式数据库应用的案例.docx_第3页
大型分布式数据库应用的案例.docx_第4页
资源描述:

《大型分布式数据库应用的案例.docx》由会员上传分享,免费在线阅读,更多相关内容在工程资料-天天文库

1、大型分布式数据库应用的案例  做大型数据库应用的时候,随着数据量越来越大,计算越来越复杂,对于性能的挑战越来越大。我们只能去使用现有的数据库方案:比如SQLSERVERCluster或者OracleRAC等,但是这也就等于走上了一条烧钱的道路,小则几十万,大则上百万乃至更多,另外还是解决不了维护的问题,要改一个表或者还原一次数据库都得几个小时或者更长的时间。最根本的办法还是像google那样有成千上万的中小型机器来代替超大型机器,每一次查询都会由几十台上百台机器来负载的分布式计算才是趋势。这里给大家介绍一个类似的数据

2、库上的相关案例1背景    我们知道数据是一个公司的命脉,随着业务越做越大,数据量也会越来越大,计算也会越来越复杂,性能,可靠性,可扩展性的需求就会越来越强烈,这个时候一个集中式的数据库显然已经满足不了需求了。对于技术决策者来说有两条路可以走,第一:按照现有的大型数据库的解决方案,比如SQLSERVERCluster或者OracleRAC等,但是这也就等于走上了一条烧钱的道路,小则几十万,大则上百万乃至更多;第二:使用真正能够扩展的分布式数据库,利用中小型服务器甚至是PC机的累加来替代大型的服务器,这也是很多公司希望

3、的,却苦于没有合适产品,现在有了ClusterKiller,用它真正能给您带来:高性能,高可用性,高扩展性,高性价比。2方案比较    2.1SQLSERVER的集群模式 这种结构只能说是一种故障转移的机制,当有一个节点出现问题后把负载转移到另一个节点上。在负载能力上和扩展性上没有任何办法,而且还浪费了硬件资源    2.2OracleRealApplicationClusters(RAC) OracleRac最多可支持64个节点,基本上算是解决了性能,扩展性的问题了,但是它在存储上还是一个单点,且不说出现故障怎么办

4、,IO也可能会成为性能瓶颈。我们都知道一个数据库大到一定程度的时候,在物理上分区才能从根本上解决问题,对几十万数据进行查找和几百万上千万的数据进行查找在系统的消耗上以及响应时间上有着几何级的降低。    2.3ClusterKiller 从图例中可以看出,下面的像网格一样的机器叫数据层,每个机器上存储着数据全集的一个分区,每一行组成一个数据全集,每一列是某个分区的多份相同的数据从而达到查询时负载均衡的效果,同时也是高可用性的保障:某个列的机器出现问题后其他的机器会负载访问。为了不让这样一个复杂的结构暴露给应用程序,在

5、数据层上面又放了一层机器叫中间层,中间层机器的数据库中驻留着的中间件来处理SQL语句,根据SQL语句的类型和条件来决定由哪些机器来提供服务。在中间层的外面加一个负载均衡设备,这样应用程序或者开发/维护的人员通过负载均衡设备连接到中间层的任意一台机器上操作,感觉就像还在使用原来的一个数据库那样,易用性非常好。 以下从各个角度具体的说明一下:开发:中间件是宿主在数据库中的,所以面对数据库写SQL语句的方式没有改变,只需要把SQL语句从语法的角度上封装一下即可。还是利用原有的数据库的管理工具,不需要使用的新的管理工具,不需

6、要改变原有的使用习惯,不需要学习新的知识。    数据库维护:对于维护表,存储过程,安全等数据库对象还是像使用一个数据库那样在中间层的任意一台机器上执行,中间件会抓取到更改并分发到其他的机器上。不会增加额外的工作量。    机器维护:因为这个结构比集中式的结构在机器的数量上要增加了很多,所以在机器层面上的维护成本比以前要有所增加。不过对于机器的维护不会影响整个结构的可用性,只需要在中间层的任意一台机器上更改一下配置就可以把某台机器添加到结构中或从结构中移出。    诊断:当出现异常后会明确的指定出错原因以及出错的机器

7、,另外还有执行日志详细的记录每个执行步骤的细节。    分区:支持多种数据类型的分区,分区方式有静态分区和线形增长两种方式。静态分区不言而喻就是一开始就要规划好分区的个数;线形增长方式就是一开始只有一个或少数几个分区列,随着数据量和访问的增长的时候再添加新的分区从而达到了线性扩展的效果    总结:中间件的定位和作用是只是把很多的数据库服务器联合起来最终实现高扩展性,高可用性以及高性能。许多关键的数据库技术比如事务,连接池,锁,安全等还是依靠数据库来完成,无论从研发成本还是实施的风险都降到最低。 2.4指标比较   

8、 故障转移/可靠性    SQLSERVERCluster:能做到前面的计算节点的故障转移,后面的存储设备还是单点    OracleRAC:能做到前面的计算节点的故障转移,后面的存储设备还是单点    ClusterKiller:从每个维度上都是可扩展的,所以无论从哪个维度上的机器损坏以后都能找到替代者从而实现故障转移。    负载均衡   

当前文档最多预览五页,下载文档查看全文

此文档下载收益归作者所有

当前文档最多预览五页,下载文档查看全文
温馨提示:
1. 部分包含数学公式或PPT动画的文件,查看预览时可能会显示错乱或异常,文件下载后无此问题,请放心下载。
2. 本文档由用户上传,版权归属用户,天天文库负责整理代发布。如果您对本文档版权有争议请及时联系客服。
3. 下载前请仔细阅读文档内容,确认文档内容符合您的需求后进行下载,若出现内容与标题不符可向本站投诉处理。
4. 下载文档时可能由于网络波动等原因无法下载或下载错误,付费完成后未能成功下载的用户请联系客服处理。