我使用负载沉重的Redshift集群与一些复杂的视图连接巨大的表，在挑选时间许多用户查询这些视图，这导致一些性能问题，我使用金属化的视图来预计算一些连接和聚合，但它不适合我，因为他们不正常刷新，我也使用不同的排序键，因为Redshift没有索引，但这个解决方案并没有提高性能，以及，所以我在考虑使用一些聚合表来模拟OLAP多维数据集之类的东西，以提高查询的性能，有什么想法或建议吗?
你提到了"复杂视图";我所见过的最大的性能窃取者之一是编写糟糕的查询。循环连接、大量扩展数据然后进行DISTINCT，以及重复的全表扫描会使任何查询都非常缓慢。我并不是说这些事情正在发生，但在进行大规模更改之前，值得确保查询是最佳的。
你没有提到表的分布键。这可能会对集群性能产生很大影响。错误的DISTKEY和数据可能在查询执行期间多次在集群网络中传输。确保"节点本地";当数据集很大时(在查询的早期)，操作可以节省大量的执行时间。
你提到了"高峰时间"。当你的观点的表现是最引人注目的。是只有您的视图在这些高峰时间运行，还是其他重负载活动正在进行?您可以看到，Redshift有许多属性在运行的所有查询之间共享，这些查询可能会被总工作负载过载。在这些情况下，运行良好的查询由于这些其他工作负载过度使用共享属性而变得太慢。这些贪婪的查询可能是造成问题的主要原因。您通常会寻找对网络和/或磁盘使用较多的查询。还有其他一些地方贪婪的查询击中红移，但这是最常见的两个。
物化视图是一个很好的尝试路径。你说没有正确刷新。这里是否有单独的问题需要调查，还是你的案例中有一些一般的限制?让物化视图工作可能是一个赢家，但您可能已经用尽了这种方法，并且知道没有解决方案可以在您的情况下工作。
汇总表是一个很好的解决方案，但有一些成本。首先，您需要生成所需的摘要，并使其保持最新。您还需要让用户转而使用这些摘要而不是基本数据。在定义、更新和确保这些汇总表之间的数据一致性方面有相当多的工作要做。我想确保我已经做了所有有意义的优化，然后再咬它。
作为开始，我将通过汇总来自这些系统表的信息来总结集群负载:
- stl_nestloop
- stl_scan(查找perm表和内部工作表的扫描量)
- stl_dist
- stl_return
- stl_wlm_query
- stl_commit_stats
您将需要聚合以了解哪些查询在这些高峰时间花费了很长时间/使用了大量资源。使用视图的查询是否占用资源，或者它们是其他贪婪查询的受害者。