我在一家人才类网站工作，长期以来一直使用SQL Server数据库，也觉得很好，上手特别容易，工具也非常方便。最近在实际工作中遇到一个问题：随着我们的发展，企业的数据量和访问量也会迅猛增加，而这个时候数据库就会面临很大的负载和压力，数据库会成为系统的瓶颈。这时就考虑到升级，但是具体怎么升？大家展开了激烈的讨论，内部形成两种不同的意见：方案一：升级到ORACLE平台，采用“RAC”来解决，为此特意请ORACLE公司的DBA到公司介绍了方案。其中讲到ORACLE“RAC”采用共享缓存（Cache）的办法，来是实现锁的互换，多个实例同时分担负载。不但能负载均衡而且扩展也很方便。同时也和微软集群（MSCS）和SQL2005 镜像作了对比。大致是这样一个结论，微软的集群解决方案中都有下面的毛病：
1.数据库只运行在一个节点上，当出现故障时，另一个节点只是作为这个节点的备份；
2.因为始终只有一个节点在运行，在性能上得不到提升，系统也就不具备扩展的能力；
3.当现有机器的性能不能满足应用的负载时，只能更换更高配置的机器；
听起来这个是可以解决问题，越交流越发现一些问题，首先“RAC”的价格问题，太贵了；其次要将应用移植，代码要重新编写，关键是有好多旧系统在里面，当时开发的人员都离开了。所以这将是一个即费财力、物力、人力，同时还要面临很大风险的一个艰难过程。方案二：一部分技术人员说换大机器吧，没办法了，因为该优化的优化了；但是根据实际的应用和以往升级的经验得出以下结论：
1.升级到综合性能更强大的硬件，带来的问题是硬件的浪费，一次性的投资增加。
2单节点体系结构最终会达到一个瓶颈并无法实现进一步的有效扩展。具体表现为逐渐缩小的回报率或者价格惊人的昂贵硬件设备。系统得不到可持续的扩展，不能从根本上解决问题。因为有些系统服务器更换时间也不长。
所以我就在琢磨，能不能就在微软平台上解决这一问题，找到一种即保证高可用性，又实现高性能，可以负载均衡的解决方案。在今年的tech.ed2008 上，特意带着这个问题到会上与微软的相关技术人员交流，如何来解决上面的问题，得到的结论是在未来的数据库中会有，但是哪个版本待定。
大会开完后我就在网上找关于数据库负载均衡集群的资料，在SQL Server 上没看到么合适的，但在开源上好多人在研究这类技术，一些第三方的软件也有，有基于数据库的，有基于网关的，也有基于磁盘的。基本的机理是通过一个软件，保证同时有多个实时、同步、可用的数据服务，也可能是多个实时、同步、完全一致的冗余数据库。这样可以对读带来负载均衡。
不知道大家有没有遇到类似的问题，能不能就这个话题进行深入探讨，共同分享经验，解决实际中遇到的问题。
欢迎大家交流:[email protected]
1.数据库只运行在一个节点上，当出现故障时，另一个节点只是作为这个节点的备份；
2.因为始终只有一个节点在运行，在性能上得不到提升，系统也就不具备扩展的能力；
3.当现有机器的性能不能满足应用的负载时，只能更换更高配置的机器；
听起来这个是可以解决问题，越交流越发现一些问题，首先“RAC”的价格问题，太贵了；其次要将应用移植，代码要重新编写，关键是有好多旧系统在里面，当时开发的人员都离开了。所以这将是一个即费财力、物力、人力，同时还要面临很大风险的一个艰难过程。方案二：一部分技术人员说换大机器吧，没办法了，因为该优化的优化了；但是根据实际的应用和以往升级的经验得出以下结论：
1.升级到综合性能更强大的硬件，带来的问题是硬件的浪费，一次性的投资增加。
2单节点体系结构最终会达到一个瓶颈并无法实现进一步的有效扩展。具体表现为逐渐缩小的回报率或者价格惊人的昂贵硬件设备。系统得不到可持续的扩展，不能从根本上解决问题。因为有些系统服务器更换时间也不长。
所以我就在琢磨，能不能就在微软平台上解决这一问题，找到一种即保证高可用性，又实现高性能，可以负载均衡的解决方案。在今年的tech.ed2008 上，特意带着这个问题到会上与微软的相关技术人员交流，如何来解决上面的问题，得到的结论是在未来的数据库中会有，但是哪个版本待定。
大会开完后我就在网上找关于数据库负载均衡集群的资料，在SQL Server 上没看到么合适的，但在开源上好多人在研究这类技术，一些第三方的软件也有，有基于数据库的，有基于网关的，也有基于磁盘的。基本的机理是通过一个软件，保证同时有多个实时、同步、可用的数据服务，也可能是多个实时、同步、完全一致的冗余数据库。这样可以对读带来负载均衡。
不知道大家有没有遇到类似的问题，能不能就这个话题进行深入探讨，共同分享经验，解决实际中遇到的问题。
欢迎大家交流:[email protected]
解决方案 »
免费领取超大流量手机卡，每月29元包185G流量+100分钟通话, 中国电信官方发货