使用 SQL Server 进行实时聚合和非规范化的架构推荐

Posted 2023-02-15

【中文标题】使用 SQL Server 进行实时聚合和非规范化的架构推荐

【英文标题】：Architecture recommendation using SQL Server for real-time aggregation and denormalization

【发布时间】：2013-06-01 18:29:06

【问题描述】：

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

问题在于，实际上，数据的只读仓库类型副本可以更好地满足研究用户的大部分需求，但需要在附近不断复制实时（几分钟的延迟就可以了）。

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

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

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

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

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

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

更新到 #3：发布后，我发现 this SO answer 使用更改跟踪、服务代理、SSIS 和触发器链接到 Real Time Data Integration - 看起来很有希望 - 这是推荐的路径吗？

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

【问题讨论】：

这里没有什么大的答案，但这显示了在初始化复制后如何运行脚本：englishtosql.com/english-to-sql-blog/2010/9/13/…。

@Sam 因此，如果我的快照后脚本创建了一个不在发布者中的新订阅者表，并且在与发布者匹配并接收事务更新的表之一上创建了一个新订阅者触发器......那触发器发布事务更新时会触发并向我的新表添加数据吗？

【参考方案1】：

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

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

【讨论】：

谢谢。如果没有使用 SSBS，您能否简要描述一下您的解决方案？

对不起我的英语.. 我的解决方案使用 SSBS，所以我推荐给你。我对使用 SSBS 感到满意，尽管它有其自身的缺点，但它非常适合我的任务。

糟糕，我同时也是。对不起！无论哪种方式，感谢您对 SSBS 的反馈。我将继续研究它作为首选方法。