【问题标题】:Strategy to keep updated summary tables standing by (SQL Server)保持更新的汇总表备用的策略(SQL Server)
【发布时间】:2013-04-24 07:10:08
【问题描述】:

我有一个客户端门户项目(我开发的第一个项目,所以基本的最佳实践就是我在这里寻找的,没什么特别的)即将发布第一个版本。

报告中使用的主要记录类型的简化如下:

CREATE TABLE [dbo].[conversions](
    [conversion_id] [nvarchar](128) primary key NOT NULL,
    [click_id] [int] NULL,
    [conversion_date] [datetime] NOT NULL,
    [last_updated] [datetime] NULL,
    [click_date] [datetime] NULL,
    [affiliate_affiliate_id] [int] NOT NULL,
    [advertiser_advertiser_id] [int] NOT NULL,
    [offer_offer_id] [int] NOT NULL,
    [creative_creative_id] [int] NOT NULL,
    [conversion_type] [nvarchar](max) NULL)

CREATE TABLE [dbo].[clicks](
    [click_id] [int] primary key NOT NULL,
    [click_date] [datetime] NOT NULL,
    [affiliate_affiliate_id] [int] NOT NULL,
    [advertiser_advertiser_id] [int] NOT NULL,
    [offer_offer_id] [int] NOT NULL,
    [campaign_id] [int] NOT NULL,
    [creative_creative_id] [int] NOT NULL,
    [ip_address] [nvarchar](max) NULL,
    [user_agent] [nvarchar](max) NULL,
    [referrer_url] [nvarchar](max) NULL,
    [region_region_code] [nvarchar](max) NULL,
    [total_clicks] [int] NOT NULL)

我的具体问题是:鉴于每个表中有数百万行,如果您知道所有可能的报告可以申请吗?

从性能角度出发,对最繁忙的客户的 18 个月数据进行原始查询会在我的仪表板上产生 3 到 5 秒的延迟,最坏的情况是超过 10 秒的摘要报告跨越所有行的自定义日期范围。

我知道我可以在第一次点击后缓存它们,但我希望在第一次点击时获得快速的性能。

我的感觉是,这是这种性质的应用程序的一个基本方面,并且有大量这样的应用程序,所以有没有一种已经深思熟虑的方法来预先计算已经进行分组的表和聚合?那么如何让它们保持最新状态?您是否使用预先强制计算的 SQL 代理和自定义控制台应用程序?

任何一般性的指针将不胜感激..

【问题讨论】:

  • 为什么不使用Multidimension Cubes SSAS,它可以帮助实现快速查询性能,因为它预先计算或聚合数据
  • 如果我知道它们是什么,我可能会使用它们;)我肯定会做谷歌搜索

标签: sql-server web-applications query-optimization reporting portal


【解决方案1】:

两个表都是时间序列。它们似乎被一个 ID 列聚集在一起,对于如何查询时间序列几乎没有价值。时间序列几乎总是按日期范围查询,因此您的集群组织应该首先为此类查询提供服务:按日期集群,将 ID 主键约束移至非集群。

CREATE TABLE [dbo].[conversions](
    [conversion_id] [nvarchar](128) NOT NULL,
    [conversion_date] [datetime] NOT NULL,
    ...
    constraint pk_conversions nonclustered primary key ([conversion_id]))
go

create clustered index [cdx_conversions] on [dbo].[conversions]([conversion_date]);
go

CREATE TABLE [dbo].[clicks](
    [click_id] [int] NOT NULL,
    [click_date] [datetime] NOT NULL,
    ...
    constraint [pk_clicks] nonclustered [click_id]);
go

create clustered index [cdx_clicks] on [dbo].[clicks]([click_date]);

此模型将服务于按[click_date][conversion_date] 上的范围过滤的典型查询。对于任何其他查询,答案将非常具体地针对您的查询。

关系行组织模型对于像您这样的 OLAP/DW 工作负载的有用程度是有限的。专业工具在这方面做得更好。 Columnstore indexes 可以提供惊人的快速响应,但它们是 difficult to update。创建MOLAP cube 也可以带来惊人的结果,但这是一项严肃的项目任务。甚至还有专门的time series databases

【讨论】:

  • 感谢您的见解 - 鉴于我遇到这个问题时不知道从哪里开始,它非常有用和赞赏
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2021-10-25
  • 2014-08-15
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多