ITPUB论坛 » MS SQL Server » 关于“大型集团企业数据同步方案”的不同看法
新一届的微软MVP评选已经开始,欢迎各位推荐!
2008-7-2 05:11 fxiong
关于“大型集团企业数据同步方案”的不同看法

最近看到论坛上一个关于“大型集团企业 SQLSERVER 2000 数据同步方案”的帖子,
有几点疑问,希望能和大家探讨一下,

对于一个大型企业,其工作数据库应该是相当繁忙的,
在这种情况下快照同步往往不能满足同步要求,在主服务器
故障时也无法用快照备份来快速恢复原数据库。所以我在这里
主要讨论事务复制的情况。

在一个繁忙的服务器上添加新的数据同步作业,必然会和其他
作业争强硬件资源,造成该工作服务器的性能下降。事务复制
的过程中,事件在从发布服务器到订阅服务器复制中存在延迟,
这个延迟的存在造成当发布服务器故障时,无法确定订阅服务器
是否已经完全复制了所有事物,所以存在事务(transaction)丢失
的可能性。

另外,原事务同步方案隐含了另外一个假设:订阅服务器的处理
速度必须快于发布服务器,否则订阅服务器无法跟上发布服务器,
会造成分发服务器内的事务队列爆满,以致发布服务器必须减速
处理新事务来等待订阅服务器。这也会降低原工作服务器的性能。
而一般企业都会把最好的硬件设备作为主工作服务器,这就很容易
造成事务队列的爆满。

即使在发布服务器和订阅服务器上使用同样的硬件,因为服务器
内部都使用了并行处理技术,而在事务复制时的队列原理造成了
该复制过程必然为单线程过程,这种先天的限制会成为整个数据库
结构的瓶颈,同样会降低整个系统的性能。

由于在上述复制方案中使用了多个服务器,根据概率,整个系统内
的服务器越多,其可靠性越差(无论是发布服务器故障还是订阅
服务器的故障,整个系统都必须停下来维修)。这可以简单归纳为
1+1<1,所以原文的方案并没有提高整个数据库的可靠性。

综上所述,我个人认为在“大型集团企业 数据同步方案”
一文中提到的几种方案都不能满足作业繁忙的大型的企业数据库系统。
相反,其同步方案的直接结果很可能是整个系统的性能和可靠性
比原来的单独运行的工作数据库服务器还要低。

2008-7-2 08:41 luckyrandom
个人观点:
或许各有各的实现方案和途径
不是每台服务器负荷都有99%<即使是官方推荐的75%,即该升级硬件>
不是每个业务都需要99.999%的可用性

在SQL SERVER 2000平台,复制同步是好的选择<虽然订阅服务器以单线程成了瓶颈>
或Stand by,但也有其自身限制

也支持更多的人根据实际应用来充分讨论这个话题或方案,及实施心得、经验
偶没机会应用这些案例,只能按文档或测试去推测,呵呵

2008-7-2 10:06 fxiong
回复 #2 luckyrandom 的帖子

我们讨论的前提是大型企业的数据库,随着企业
的发展,对数据库服务器的负荷增长远高于硬件
提速的速度。而且硬件的升级有很多限制,当前发展
已经趋近物理极限,我个人认为硬件升级的办法
无法解决数据同步的问题,至多是把问题的紧迫性
向后推延6~12个月。

2008-7-2 16:53 petertse
一般来说,按企业的规划,如果算得上是"大型企业"的话,服务器或者数据库的功能会进一步细化,从而会有更多的硬件负责不同的数据库.
比如,前端服务器中间服务器后台服务器(存储容灾)会分别负责不同功能,
将一些出现的瓶颈可能情况提前放在中间或者前端来解决.
不过这些关乎钱的问题,大企业,应该不缺钱......

2008-7-3 08:54 luckyrandom
我想企业业务增长速度远高于<或高于>硬件提速的案例相当的少,呵呵
数据应用需求是无极限的,作为企业决策者或IT决策者必定会区分哪些投资是有性价比和价值最大化的
每个方案都需要综合权衡性能、可用性、成本,很能达到某一个极端/极限
比如一个大型的分析服务SERVER,查询一个分析报表需要20分钟和30分钟,区别并不明显

大型企业也不是神,也不会要求系统达到实时的极限和完美

页: [1]


Powered by ITPUB论坛