mdi*_*bio 5 sql-server full-text-search data-warehouse service-broker transactional-replication
我们有一个企业LOB应用程序,用于使用SQLServer(2008)管理数百万个书目(大量文本)记录.数据库非常规范化(完整记录可能很容易由十个连接表加上嵌套集合组成).写交易很好,我们现在有一个非常敏感的搜索解决方案,它慷慨地使用全文索引和索引视图.
问题是,在现实中,许多内容研究用户需要,可以更好地提供服务的只读仓储式拷贝数据,但它需要近乎实时地连续复制(几分钟的等待时间是精细).
我们的搜索已经通过几个计算列或复合表进行了优化,我们希望添加更多.索引视图由于其约束(例如没有外部联接)而无法满足所有需求.这些数据有许多"方面",就像只读数据仓库可能提供的那样,涉及权限,地理位置,类别,质量和相关文档的数量.我们还组成了相当静态的记录的复杂xml表示,可以组合和存储一次.
如果完全通过触发器完成,则非规范化,计算和搜索优化的总量会引起不可接受的延迟,并且还容易发生锁定冲突.
我已经研究了一些Microsoft的SQL Server建议,我想知道是否有任何具有类似要求经验的人可以提供以下三个建议(或其他使用SQL Server/.Net堆栈的建议):
事务性复制到只读副本 - 但是从文档中不清楚可以在订户端更改模式并添加触发器,计算列或组合表;
表分区 -不改变数据,但也许是为了数据的段大面积,目前正在不断重新计算,例如权限,记录类型(60),地理区域等...将允许在事务侧触发运行少锁？
离线批处理 - 微软经常使用该短语,但除了在交易复制的订户端"检查信用卡欺诈迹象"之外,没有提供很好的例子......这将是一个很好的样本,但是如何完成究竟在实践中？每5分钟运行一次的SSIS工作？服务经纪人？连续轮询的外部可执行文件？我们要避免"跑,晚上一个漫长的过程"解决方案,我们也想避免被交易服务器上运行的更新密集聚集/合成日常每5分钟的事情事务副锁定了.
更新到#3:发布后,我发现这个SO答案带有使用变更跟踪,服务代理,SSIS和触发器的实时数据集成的链接- 看起来很有希望 - 这是推荐的路径吗？
另一个更新:反过来,它帮助我找到rusanu.com - 所有东西ServiceBroker由SO用户Remus Rusanu.异步消息传递解决方案似乎比复制方案更好地匹配我们的场景......
Service Broker 技术非常适合为您的任务提供服务，尽管根据您的特定系统配置可能存在潜在的缺点。IMO 最有价值的功能是能够解耦两种处理——写入和聚合。即使使用不同的数据库/SQL Server 实例/物理服务器，您也可以以非常可靠的方式执行此操作。当然，您需要花一些时间设计消息交换流程 - 指定消息格式、规划对话等，因为这对最终系统的满意度有很大影响。
我使用 SSBS 来完成或多或少相似的任务 - 基于常规数据流近实时创建分析数据仓库。