Ann*_*nna 5 performance data-warehouse database-design sql-server ssrs
我真的需要一些帮助。
\n\n这是我的情况。
\n\n我正在 SQL Server 2005 中构建一个数据集市，它将提供一个报告（目前）。我们有 26 个客户（医疗组织）将使用此报告。每个客户端在任何给定时间都会有 1 到 2,000 个用户访问它（最有可能平均为 50 个，但需要扩展）。同一 rdl 将有 26 个版本，每个客户端一个。每个人都将访问自己各自的客户数据库。
\n\n该报告的界面是SSRS 2012。这是我们第一个2012年的报告 - 其余的仍然是2005年的，rdl将访问2005年的数据库。我没有使用 OLAP；SSRS 报告运行 SP 和视图。
\n\n我们构建了一个虚拟服务器并安装了 SQL 2012 来托管报告（如果重要的话，这两个虚拟服务器都位于同一台物理计算机上）。SQL 2012 虚拟服务器上不会运行任何其他内容。
\n\n这些都是关于环境的事实......
\n\n我们的系统不是 OLTP 重型系统 - 除了一个例外（我将在下面描述），它都是读取（当然 ETL 除外）。
\n\n我们为每个客户提供一个面向客户的数据库，总共 26 个。在其中，我们存储事务数据、汇总数据、一些准备报告的平面表以及大量 T-SQL 代码，这些代码在客户端在 SSRS 中提取报告时处理数字。我将这些数据库称为“可操作”数据库，因为对我来说，它们本质上将充当 ODS 的功能。
\n\n操作数据库通过可怕的 ETL 过程加载（客户端有不同的加载计划 - 通常每月或每周）。我将构建一个小型 ETL 流程（希望不是那么可怕）来从这些操作数据库填充数据集市。
\n\n数据集市的所有维度都是一致的，但由于 HIPAA 限制，其中一些维度（如医生和患者）无法存储在中央数据库中，事实表也不能存储在中央数据库中。因此，需要有 26 个版本的相同事实和维度表，每个客户端一个。
\n\n我们的系统有一个实时组件。医生和护士可以通过我们的网站输入交易数据，所有报告都需要立即反映变化。至于数据集市，它们只会影响事实表。无论如何，这就是我决定不使用 SSAS 的原因。我知道差异处理速度非常快，但感觉就像有太多移动部件。
\n\n我计划创建一个trickle-in事实表，并使用一个将其与主事实表相结合的视图。同样，我需要 26 个。我的新 ETL 流程的精简版本将需要在每次用户编辑时运行。
\n\n这是我的问题...
\n\n带着所有这些问题，我\xe2\x80\x99m 关心良好的设计实践，但主要关心的是报告的性能以及需要在用户编辑时运行的 ETL 的性能。
\n\n我希望这一切都是有道理的。我将非常感谢任何反馈！
\n\n编辑：@Jon Seigel - 相同的 rdl 将有 26 个版本，每个客户端一个。每个人都将访问自己各自的客户数据库。
\n\n编辑：@JNK - 我合并了帐户并阅读了常见问题解答。希望我现在的反应是正确的。
\n我最初的想法是每个客户端使用两个数据库的解决方案，一个用于数据集市，一个用于 ODS。ODS 将处于完全恢复模式，因为我认为如果不从客户端的上游源再次检索数据，您就无法在此处重新创建数据（如果有的话）。数据集市可能处于简单恢复模式，因为所有源数据都来自 ODS，并且可以在需要时从头开始重新加载，但滴流事实表使其变得复杂。我倾向于将事实表移至 ODS 中，以便在进入数据集市之前有更好的选择来强制实施 RI 和其他数据清理需求（可能通过 DML 触发器或单独计划的 ETL）。此外，如果您可以使数据集市数据库在 ETL 周期之间只读，那么您将受益于 SQL 不必在报告请求期间管理锁。
我认为您无法选择使用中央架构/数据库来存储非敏感内容。从可扩展性的角度来看，将每个客户端的数据结构放在自己的容器中，您可以根据需要将选项迁移到更快的磁盘或另一台主机，而不会影响其他客户端或维持更长的停机时间。从业务逻辑的角度来看，如果特定客户端需要影响架构的业务规则更改，中央数据库是否能够在不产生负面影响的情况下容纳它？另外，从可扩展性的角度来看，请考虑由于一个客户端影响并发连接的其他客户端而导致表上的锁定所带来的风险。
| 归档时间： |
|
| 查看次数： |
584 次 |
| 最近记录： |