报告系统架构以获得更好的性能答案

【问题标题】：Reporting System architecture for better performance报告系统架构以获得更好的性能
【发布时间】：2010-03-30 16:35:40
【问题描述】：

我们有一个运行 Sql Server Express 2005 并主要使用 ASP.NET 的产品。该数据库有大约 200 个表，其中少数（4 或 5 个）每天可以从 300 行增长到 5000 行并保持 5 年的历史记录，因此它们可以增长到 1000 万行。
我们建立了一个报告平台，允许客户基于模板、字段和过滤器构建报告。
我们几乎从一开始就面临性能问题，我们尝试将报告显示时间保持在 10 秒以下，但其中一些会达到 25 秒（特别是对于那些历史悠久的客户）。
我们不断检查索引并尝试改进查询，但我们觉得我们能做的只有这么多。当然，查询是动态生成的这一事实对优化没有帮助。我们还添加了一些保留冗余数据的表，但随之而来的是维护这些数据是最新的问题，而且 Sql Express 对数据库的大小有限制。
我们现在面临一个问题，即我们必须决定是否要放弃实时报告，或者是否可以删除历史记录以获得更好的性能。
我想问一下这种系统的推荐方法是什么。
另外，我们应该开始寻找第三方工具/平台吗？我知道 OLAP 可以是一个选项，但我们可以让它在 Sql Server Express 上运行，或者至少使用一个足够便宜的许可证来分发到数千个部署？

谢谢

【问题讨论】：

标签： performance architecture reporting sql-server-express

【解决方案1】：

我们几乎面临性能问题从一开始就

在您的桌子变大之前？这让我认为您的报告应用程序或 SQL 查询存在潜在问题。系统上只有 1 个用户会出现这些等待时间吗？

您是否使用过 SQL 跟踪来记录长时间运行的查询并修复它们？你是如何添加索引的？

有开源 OLAP 套件 - http://www.pentaho.com/index.php 但我不能保证它的易用性或性能。

【讨论】：

是的，out 应用程序主要由 1 人访问。我们多次致力于查询改进、分析执行计划和添加索引。我们改进了许多查询，但对于某些报告，似乎不可能降低到 1 秒查询。
为了能够动态构建查询，我们使用视图来收集字段，这些字段可能直接来自表或来自通过计算或分组的数据转换。我想这会妨碍查询构建的充分灵活性，但即使我们尝试手动构建不同的查询来获得相同的结果，性能似乎也不会好很多。
我们的表从一开始就很大，因为数据是从以前的系统迁移过来的。
我们目前正在进行查询优化，并且通过更改查询或添加索引，事情变得越来越快。但我仍然觉得这种方法既困难又昂贵（在时间和资源方面），我想知道如果我们有更多类似 OLAP 的系统，事情会变得更容易和更快。
OLAP 将是一项完全不同的举措，即使设置一个简单的项目也需要相当多的时间——但从长远来看，它可能会更好。您是否探索过减少连接数量的选项？ technet.microsoft.com/en-us/library/cc917715.aspx 。这就是 Dave Swersky 在理论上所指的 - 索引视图可能允许您添加它而无需实际添加非规范化表。

【解决方案2】：

可以通过维护数据库的非规范化版本来改进这种情况下的查询执行。 SQL Express 没有提供太多“开箱即用”的 BI 方式，因此您最好的选择（在 SQL Express 的限制内）是手动设计解决方案。

这意味着设计数据库的非规范化版本，您可以将数据导出到该版本以进行报告。请注意，非规范化数据库占用更多空间。 Here 是一本关于设计数据仓库的书。

您还应该研究将数据集中在功能齐全的 RDBMS 中的架构选项。

【讨论】：