在SQL数据库之间共享数据

Question

我正试图解决一个问题,一次,我没有创造.

我在一个环境中工作,有许多Web应用程序由不同服务器上的不同数据库支持.

每个数据库在设计和应用方面都相当独特,但我仍想提取每个数据库中的常见数据.例如,每个数据库都有供应商表,用户表等......

我想将这个常见数据抽象到单个数据库,但仍然让其他数据库加入这些表,甚至还有密钥来强制执行约束等等......我在MsSql环境中.

有哪些选择？我看到它的方式,我有以下选择:

• 链接服务器
• 只读登录以访问视图

还有什么需要考虑的吗？

Answer 1

有很多方法可以解决这个问题.我强烈推荐解决方案1,2或3,具体取决于您的业务需求:

1. 事务复制:如果公共数据库是帐户记录,并且您希望为单独的应用程序提供数据的只读版本,则可以将核心表(甚至可能只是表的核心列)复制到每个单独的服务器.这种方法的一个好处是您可以根据需要复制到任意数量的订户数据库.这也意味着您可以根据需要自定义订阅者可以使用的表和字段.因此,如果一个应用程序需要用户表而不是供应商表,那么您只需订阅用户表.如果另一个只需要供应商表而不需要用户表,那么您只能订阅供应商表.另一个好处是复制保持自身同步,如果出现问题,您可以随时重新初始化订阅.

   我使用事务复制从数据仓库中推出超过100个表,以分离需要访问来自多个系统的聚合数据的下游应用程序.由于我们的数据仓库是按镜像和日志传送数据源按小时计划更新的,因此生产应用程序在每小时20到80分钟的滑动窗口内有来自众多系统的数据.

   作为发布类型的Peer-to-Peer事务复制可能更适合您提供的用例.如果要逐节点地逐步推出架构或复制更改,这可能非常有用.标准事务复制在此方面有一些限制.

   快照复制发布类型比事务发布具有更多延迟,但如果可接受一定程度的延迟,您可能需要考虑它.

   虽然您提到您是Microsoft SQL Server商店,但请记住其他RDBM具有类似的技术.由于您专门讨论MS SQL Server,请注意事务复制也允许您复制到Oracle数据库.因此,如果您的组织中有一些这样的解决方案,此解决方案仍然有效.

   使用事务复制的一个缺点是,如果中央服务器出现故障,您可能会在复制对象的下游副本中遇到数据延迟.如果复制的对象(文章)非常大并且您需要重新初始化表,那么这也可能需要很长时间.

2. 镜像:如果要在下游服务器上实时访问数据库,则最多可以设置两个异步镜像.我以这种方式将数据与CRM应用程序集成在一起.所有读取都来自镜像的连接.所有写入都被推送到消息队列,然后将更改应用到中央生产服务器.这种方法的缺点是您不能创建超过2个异步镜像.除非您计划将镜像用于灾难恢复,否则您不希望将同步镜像用于此目的.

3. 消息传递系统:如果您希望有许多单独的应用程序需要来自单个中央数据库的数据,那么您可能需要考虑企业消息传递系统,如IBM Web Sphere,Microsoft BizTalk,Vitria,TIBCO等.这些应用程序专门用于解决这个问题.它们的实施和维护往往既昂贵又繁琐,但如果您拥有全球分布式系统或数十个需要在某种程度上共享数据的独立应用程序,它们可以扩展.

4. 链接服务器:听起来你已经想到了这个.您可以通过链接服务器公开数据.我不相信这是一个很好的解决方案.如果您真的想要使用此路由,请考虑设置从中央数据库到另一台服务器的异步镜像,然后设置与镜像的链接服务器连接.这至少可以降低来自Web应用程序的查询将导致中央生产数据库出现阻塞或性能问题的风险.

   IMO,链接服务器往往是一种用于共享应用程序数据的危险方法.此方法仍将数据视为数据库中的二等公民.这导致一些非常糟糕的编码习惯,特别是因为您的开发人员可能使用不同的连接方法在不同语言的不同服务器上工作.你不知道是否有人会针对你的核心数据写一个真正有意义的查询.如果您设置的标准需要将共享数据的完整副本下载到非核心服务器,那么您不必担心开发人员是否编写了错误的代码.至少从他们糟糕的代码不会破坏其他编写良好的系统的性能的角度来看.

   有很多很多资源可以解释为什么在这种情况下使用链接服务器会很糟糕.非详尽的原因列表包括:(a)用于链接服务器的帐户必须具有DBCC SHOW STATISTICS权限,否则查询将无法使用现有统计信息,(b)查询提示不能用于除非作为OPENQUERY提交,(c)与OPENQUERY一起使用时不能传递参数,(d)服务器没有足够的关于链接服务器的统计信息,因此,创建了非常糟糕的查询计划,(e)网络连接问题可以导致失败,(f)这五个性能问题中的任何一个,以及(g)在双跃点场景中尝试验证Windows活动目录凭证时可怕的SSPI上下文错误.链接服务器对某些特定方案很有用,但建议不要在技术上可行的情况下围绕此功能构建对中央数据库的访问权限.

5. 批量ETL过程:如果Web应用程序可接受高度延迟,那么您可以使用SSIS(此StackOverflow问题中的许多良好链接)编写批量ETL过程,这些过程由SQL Server代理作业执行以在服务器之间移动数据.还有其他替代ETL工具,如Informatica,Pentaho等,因此请使用最适合您的方法.

   如果您需要低延迟,这不是一个好的解决方案.在与第三方托管的CRM解决方案同步时,我已经使用此解决方案来处理可以容忍高延迟的字段.对于无法容忍高延迟(基本帐户创建数据)的字段,我们依靠在帐户生成点通过Web服务调用在CRM中创建重复记录.

6. 每夜备份和还原:如果您的数据可以容忍高延迟(最多一天)和不可用时段,那么您可以跨环境备份和还原数据库.对于需要100%正常运行时间的Web应用程序,这不是一个好的解决方案.我们的想法是您进行基线备份,将其还原为单独的还原名称,然后在新数据库准备好使用后立即重命名原始数据库和新数据库.我已经看到这对一些内部网站应用程序已经完成,但我通常不推荐这种方法.这更适合较低的开发环境,而不适合生产环境.

7. 日志传送辅助:您可以在主要和任意数量的辅助设备之间设置日志传送.这类似于夜间备份和还原过程,但您可以更频繁地更新数据库.在一个实例中,该解决方案用于通过在两个日志传送接收者之间切换来从下游用户的一个主要核心系统公开数据.有另一台服务器指向这两个数据库,并在新数据库可用时在它们之间切换.我真的讨厌这个解决方案,但有一次我看到这个实现它确实满足了业务的需要.