Performance 报告系统体系结构可提高性能

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

谢谢

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

在你的桌子变大之前？这使我认为您的报表应用程序或SQL查询中存在潜在问题。这些等待时间是否只发生在系统上的一个用户身上

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

有开源OLAP套件-

---

但我不能保证它的易用性或性能。

在这种情况下，可以通过维护数据库的非规范化版本来改进查询执行。SQL Express没有提供很多现成的BI，因此在SQL Express的约束范围内，您最好的选择是手动设计解决方案

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

---

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

是的，我们的应用程序主要由一个人访问。我们在查询改进、分析执行计划和添加索引方面做了几次工作。我们改进了许多查询，但对于某些报表，似乎不可能只进行1秒的查询。为了能够动态构建查询，我们使用收集字段的视图，这些字段可能直接来自表，也可能来自通过计算或分组进行的数据转换。我想这会妨碍查询构建的充分灵活性，但即使我们尝试手动构建不同的查询以获得相同的结果，性能似乎也不会得到很大提高。尽管我们的表从一开始就很大，因为数据是从以前的系统迁移的。我们目前正在进行查询优化，通过更改查询或添加索引，速度正在加快。但我仍然觉得，这种方法在时间和资源上既困难又昂贵，我想知道，如果我们有更多类似OLAP的系统，事情会变得多么容易和更快。OLAP将是一个完全不同的计划，即使建立一个简单的计划也会花费相当多的时间——但从长远来看，它可能会更好。您是否研究过减少连接数量的方法。这就是Dave Swersky在理论上所指的内容-索引视图可能允许您添加此内容，而无需实际添加非规范化的表。