6

我们有一个企业 LOB 应用程序，用于使用 SQLServer (2008) 管理数百万个书目（大量文本）记录。该数据库非常规范化（一条完整的记录可能很容易由十个连接表和嵌套集合组成）。写事务很好，我们现在有一个响应速度非常快的搜索解决方案，它大量使用全文索引和索引视图。

问题在于，实际上，研究用户需要的大部分内容都可以通过只读仓库类型的数据副本更好地服务，但需要近乎实时地不断复制（几分钟的延迟是美好的）。

我们的搜索已经通过几个计算列或复合表进行了优化，我们还想添加更多。索引视图无法满足所有需求，因为它们的约束（例如没有外部连接）。这些数据有几十个“方面”，就像只读数据仓库可能提供的那样，涉及权限、地理、类别、质量和相关文档的数量。我们还编写了相当静态的记录的复杂 xml 表示，并且可以编写和存储一次。

如果完全通过触发器完成，反规范化、计算和搜索优化的总量会引发不可接受的延迟，并且还容易发生锁冲突。

我研究了微软的一些 SQL Server 建议，我想知道是否有任何有类似要求经验的人可以提供以下三个建议（或其他使用 SQL Server/.Net 堆栈的建议）：

  1. 事务复制到只读副本 - 但从文档中不清楚可以在订阅方更改多少架构并添加触发器、计算列或复合表；

  2. 表分区- 不是为了改变数据，而是为了分割当前不断重新计算的大数据区域，例如权限、记录类型 (60)、地理区域等……这将允许事务端的触发器运行更少的锁？

  3. 离线批处理——微软经常使用这个短语，但没有给出很好的例子，除了在交易复制的订户端“检查信用卡欺诈的迹象”......这将是一个很好的例子，但它是如何完成的究竟在实践中？每 5 分钟运行一次的 SSIS 作业？服务经纪人？不断轮询的外部可执行文件？我们希望避免“在夜间运行长时间进程”解决方案，并且我们还希望通过在事务服务器上每 5 分钟运行一次更新密集型聚合/合成例程来避免锁定事务方面。

    • 更新到 #3：发布后，我发现这个 SO 答案带有指向使用变更跟踪、服务代理、SSIS 和触发器的实时数据集成的链接- 看起来很有希望 - 这是推荐的路径吗？

    • 另一个更新：这反过来又帮助我找到了 rusanu.com - SO 用户Remus Rusanu的所有东西 ServiceBroker 。异步消息传递解决方案似乎比复制场景更符合我们的场景......

4

1 回答 1

2

Service Broker 技术非常适合为您的任务服务，尽管根据您的特定系统配置可能存在潜在缺陷。IMO 最有价值的功能是能够解耦两种处理——写入和聚合。即使以非常可靠的方式使用不同的数据库/SQL Server 实例/物理服务器，您也可以做到这一点。当然，您需要花一些时间来设计消息交换过程——指定消息格式、计划对话等，因为这对最终系统的满意度有很大影响。

我将 SSBS 用于或多或少相似的任务 - 基于常规数据流的分析数据仓库的近实时创建。

于 2013-07-10T18:50:58.160 回答