Стратегия сохранения обновленных сводных таблиц, стоящих (SQL Server)

Question

У меня есть проект клиентского портала (первый из которых я разработал, так что основная передовая практика - это то, что я ищу здесь, ничего необычного) рядом с первым выпуск.

Упрощение основных типов записей, используемых в отчетности заключается в следующем:

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-агент и пользовательские консольные приложения, которые грубо вынуждают вычисления перед началом работы?

Любые общие указатели будут очень полезны ..

Answer 1

Обе таблицы временных рядов. Кажется, что они сгруппированы по столбцу идентификатора, который не имеет большого значения для того, как запрашиваются временные ряды. Временные ряды почти всегда задаются диапазоном дат, поэтому ваша кластерная организация должна обслуживать этот тип запросов в первую очередь: кластер по дате, переместить ограничение первичного ключа 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.