寻求有关如何将来自 100 多个客户端数据库的数据集成到集中报告数据库中的建议

Question

我是一家小型（约 50 名员工）SaaS 公司的 SQL 开发人员（不是 DBA 或架构师）。我的任务是弄清楚如何：

我已经阅读了许多关于各种技术的文章，例如事务复制（特别是多对一/中央订阅者模型）、SQL 服务代理、日志传送、变更跟踪 (CT) 和变更数据捕获 (CDC，我的理解是这仅适用于企业），我不确定最好采用哪种路径。

我希望你们中的一些具有集成专业知识的人可能遇到过与我们类似的设置，并能够为我指明一条成功的道路或指导我找到一些有用的资源。

由于成本限制，我们的解决方案必须适用于 SQL Server 标准版。此外，解决方案必须合理以在我们的小型组织内支持/维护。

基本配置：

我们目前有 100 多个单独的客户端数据库，大多数部署在我们数据中心的 SQL 服务器上，但有些部署在我们可以远程访问的数据中心内的客户端服务器上。这些都是 SQL Server 2008 R2 数据库，但我们计划很快升级到 SQL 2016。

我们使用数据库项目和 dacpac 来确保架构在将要集成的所有客户端数据库中是相同的。但是，由于我们不会强制所有客户端同时升级到新版本，因此升级之间可能存在一些架构差异。如果客户端 A 的软件版本为 1.0 而客户端 B 的版本为 1.1，则解决方案必须足够灵活，不会中断。

操作报告目前直接从每个客户的 OLTP 数据库运行。如果我们不卸载它，我们担心这会对应用程序的性能产生影响。

高级要求：

我们的客户是医院无菌处理部门 (SPD)，他们希望获得有关他们迄今为止处理的内容、库存在哪里等的最新报告。 SPD 全天候处理库存，包括周末和节假日。由于这项工作的主要目的之一是更好地支持运营报告，我们希望数据尽可能接近实时，以继续满足客户的需求。

目前，我们在不同的数据库中有一些 SPD，它们实际上是同一医院系统的一部分。这些客户希望能够针对其系统中的所有 SPD 进行报告。

从战略上讲，我们希望能够轻松汇总所有客户的数据，以支持我们的内部分析计划。我们的期望是我们能够将收集到的运营数据用作数据集市/仓库的来源。

思念至今：

事务复制似乎会提供最“实时”的解决方案。我发现此回复特别有用，但我担心潜在的架构差异对我们不起作用：SQL Server 多对一复制

考虑到在查询处于活动状态时日志无法恢复，日志传送听起来并不理想。我要么必须把每个人都踢出去，以便日志可以恢复，否则数据将变得陈旧。我不清楚这种方法是否可以用于集中来自多个数据库的数据，因为每个传送的日志只会用于它来自的单个数据库。

使用 SQL 服务代理，如果队列无法跟上要处理的消息数量，则延迟可能无法预测。

CT 只为每个表行标识一个版本。延迟取决于我们对每个数据库处理 SSIS 包之类的东西以检索数据并将其插入中央存储库的速度。

我们是否需要考虑单独复制每个数据库，然后可能使用某种数据虚拟化技术来组合来自各种复制源的数据？

您愿意提供的任何建议或方向将不胜感激。

Answer 1

我们是否需要考虑单独复制每个数据库，然后也许使用某种数据虚拟化技术来组合来自各个复制源的数据？

是的。您可以在单个实例上托管多个订阅者数据库，然后使用视图对它们进行查询，或者将它们加载到统一数据库中。