代码之家 › 专栏 › 技术社区 › Rob West

从主数据库更新从属SQL Server 2008数据库的模式,同时最大限度地减少中断

scalability replication synchronization sql-server-2008

Rob West · 技术社区 · 17 年前

我们有一个ASP.NET web应用程序,由使用SQL Server 2008的多个实例的web场托管,在该应用程序中,我们将来自多个源的数据聚合和预处理为一种优化的格式,以实现快速最终用户查询性能(在某些表中生成500-1000万行)。聚合和优化由后端服务器上的服务完成,然后我们希望将其分发到web应用程序实例使用的多个只读前端副本,以实现最大的可伸缩性。

我的问题是,如何最好地将这些数据从后端数据库输出到只读前端副本,并且在这个过程中不会降低它们的性能。前端web应用程序实例将处于恒定的高负载下,并且需要始终具有良好的响应性。

后端数据库不断更新,因此我怀疑事务性复制不是最好的方法,因为对拷贝的不断更新会影响它们的性能。

数据过时不是一个大问题,因此快照复制可能是一种方法,但这将导致复制期间的性能低下。

执行drop和bulk insert将导致时段中没有用于用户查询的数据。

我真的不想写一个复杂的集群方法,在更新过程中我们会将副本从集群中删除——有没有这样的方法可以不用花太多的精力就可以做到,或者有更好的替代方法?

3 回复 | 直到 16 年前

Remus Rusanu 16 年前

实际上,SQLServer2005(和2008)中内置了一种技术,旨在解决此类问题。 Service Broker (我将进一步称为SSB)。问题是它的学习曲线非常陡峭。

我知道MySpace公开了如何使用SSB管理他们的SQL服务器园区: MySpace Uses SQL Server Service Broker to Protect Integrity of 1 Petabyte of Data . 我知道还有几个(主要的)网站使用类似的模式,但不幸的是,它们还没有公开,所以我无法引用它们的名字。我个人参与了一些与此技术相关的项目(我曾是SQLServer团队的成员)。

现在请记住,SSB不像复制那样是一种专用的数据传输技术。因此,您将找不到任何类似于发布向导和复制的简单部署选项的内容(检查一个表,它就会被传输)。SSB是一种可靠的消息传递技术,因此其原语停留在消息交换级别,您必须编写利用 data change capture ,将其打包为消息,并将消息解包到目的地的关系表中。

logical routes 应用程序可以动态地将APT添加到新拓扑中。SSB还能够适应长时间的断开连接和停机,能够在断开连接数小时、数天甚至数月后恢复数据流。通过引擎集成(SSB是SQL引擎本身的一部分,不是卫星应用程序和复制等过程的集合)实现的高troughput意味着积压的更改可以在合理的时间内完成(我知道有些站点正在经历半个月) 一百万 每分钟交易量)。SSB应用程序通常依赖于 internal Activation 处理输入数据。SSB还具有一些独特的功能,如内置 load balancing (通过路由)具有粘性会话语义,支持 deadlock free application specific correlated processing , priority data 交付,对数据库镜像的特定支持, certificate based authentication 对于跨域操作,内置 persisted timers 还有更多。

这不是“如何将数据从服务器a上的表T移动到服务器B”的具体答案。更像是一种关于如何“在服务器a和服务器B之间交换数据”的通用技术。

Wim ten Brink 16 年前

您的客户机系统将保留数据库的本地副本,并在特定日期/时间后定期请求所有数据库修改。然后在本地数据库上执行这些修改,它将再次更新。

这将如何执行取决于后端数据库上的修改数量。但是,如果您每15分钟请求一次更改,那么每次不应该有那么多数据。

但是,我从来没有机会在实际应用中解决这个问题,所以这对我来说仍然是一个理论原则。 看起来很快,但需要做很多工作。

rmontgomery429 16 年前

:编写应用程序以使用行级事务传输数据。这可能需要更长的时间,但不会导致使用数据的站点中断,因为在读取之前和之后都有行,只有新数据。此处理将在单独的服务器上进行,以最小化负载。

在sql server 2008中,可以设置 READ_COMMITTED_SNAPSHOT 到 ON

但基本上,这个应用程序所做的就是从一个数据库读取新数据,然后再读取到另一个数据库中。

选择2 :将数据(表或整个数据库)从聚合服务器移动到前端服务器。如果可能的话,将其自动化。然后切换web应用程序以指向新的数据库或表,以备将来的请求。这是可行的,但需要对web应用程序进行控制,而您可能没有。

选择4 :您可能可以使用类似服务器的字节级复制。这听起来很可怕。这基本上是将服务器从A点复制到B点,精确到字节。它主要用于DR情况,听起来可能是某种DR情况,但不是真正的DR情况。

备选案文5