О регистрах накопления
В нескольких статьях представлены основные сведения о внутреннем устройстве регистров накопления, о SQL-запросах платформы при работе с ними и их изменение в зависимости от настроек регистра. Подробно описана работа платформы с разными типами регистров (остатков и накопления), а также принцип действия агрегатов.
Материалы созданы во времена платформы 8.2, поэтому некоторые моменты могут быть уже не актуальными, но основные принципы работы остались неизменными.
Конкретно в этой статье речь идет о механизме агрегатов оборотного регистра накопления в базе данных. Все примеры из публикации Вы можете найти на GitHub.
Предисловие
В предыдущих статьях мы говорили о структуре хранения регистров накопления в базе данных, работе платформы с виртуальной таблицей "Обороты", также "Остатки" и "Остатки и обороты" этих регистров в зависимости от настроек хранения итогов. Все эксперименты проводились на тестовой конфигурации, содержащей два регистра накопления видов "Остатки" и "Обороты" (подробнее см. в предыдущих статьях).
Сегодня в статье рассмотрим действия платформы при работе с агрегатами оборотных регистров накопления.
Что это за "зверь"?
В предыдущих статьях были рассмотрены вопросы хранения регистров накопления в SQL-базе данных, а также принцип работы платформы с виртуальными таблицами регистров и формируемые при этом платформой SQL-запросы:
- Регистры накопления. Структура хранения в базе данных
- Регистры накопления. Виртуальные таблицы. Часть №1: Обороты
-
Регистры накопления. Виртуальные таблицы. Часть №2: "Остатки" и "Остатки и обороты"
Сегодня мы коснемся возможности задействовать механизм произвольных агрегатов для регистров накопления с видом "Обороты". С их помощью можно значительно ускорить формирование отчетов по регистрам накопления в тех случаях, когда количество записей в регистре составляет сотни тысяч, миллионы и более.
Агрегаты позволяют создать заранее рассчитанные данные для формирования отчетов на подобие итогов регистров накопления. Последние рассчитываются платформой автоматически (при условии включения использования итогов для регистра) в отличии от агрегатов. Но для чего нужны агрегаты, если подобную задачу выполняют итоги?
Во-первых, итоги рассчитываются в разрезе месяцев и изменить это нельзя, в то время как агрегаты могут рассчитываться в разрезе дня, месяца, квартала, полугодия и года. Во-вторых, разрезы агрегатов могут быть произвольными (любой состав измерений регистра накопления), в отличии от итогов, которые рассчитываются по полному составу регистра.
Общую информацию об агрегатах оборотных регистров накопления Вы можете посмотреть на официальном сайте. Далее в статье мы рассмотрим создание и настройку агрегатов, а также принцип работы платформы с ними на стороне базы данных. Для примеров будет использоваться тестовая конфигурация, используемая в перечисленных выше статьях.
Создание и настройка
Пользователю понадобился отчет, показывающий обороты номенклатуры в разрезе складов по годам. Вот пример сформированного отчета:
Ничего сложного в запросе, получающем данные для отчета, нет. Используя виртуальную таблицу оборотов мы получаем общее количество оборота по годам. Вот текст запроса отчета:
"ВЫБРАТЬ
| ДвиженияНоменклатурыОбороты.ПериодГод,
| ДвиженияНоменклатурыОбороты.Номенклатура,
| ДвиженияНоменклатурыОбороты.Склад,
| ДвиженияНоменклатурыОбороты.КоличествоОборот
|ИЗ
| РегистрНакопления.ДвиженияНоменклатуры.Обороты(,
| ,
| Авто
| ,)
| КАК ДвиженияНоменклатурыОбороты"
В одной из предыдущих статей мы уже рассматривали какой SQL-запрос формирует платформа при использовании виртуальной таблицы оборотов. В нашем примере он будет следующий:
"SELECT
| T1.YearPeriod_, // Период (год)
| T1.Fld27RRef, // Номенклатура
| T1.Fld28RRef, // Склад
| T1.Fld29Turnover_ // КоличествоОборот
|FROM
| (SELECT"+
// Преобразуем период к началу года
" DATEADD(DAY,1.0 - 1,DATEADD(MONTH,1.0 - 1,
| DATEADD(YEAR,(CAST(DATEPART(YEAR,T2._Period)
| AS NUMERIC(4)) - 2000) - 2000
| ,{ts ''4000-01-01 00:00:00''}))
| ) AS YearPeriod_,
| T2._Fld27RRef AS Fld27RRef, // Номенклатура
| T2._Fld28RRef AS Fld28RRef, // Склад"+
// КоличествоОборот
" CAST(SUM(T2._Fld29) AS NUMERIC(33, 8)) AS Fld29Turnover_"+
// Данные получаем из таблицы оборотов регистра
" FROM _AccumRgTn30 T2 WITH(NOLOCK)"+
// Группируем результат по периоду, номенклатуре и складу
" GROUP BY DATEADD(DAY,1.0 - 1,DATEADD(MONTH,1.0 - 1,
| DATEADD(YEAR,(CAST(DATEPART(YEAR,T2._Period)
| AS NUMERIC(4)) - 2000) - 2000,
| {ts ''4000-01-01 00:00:00''}))),
| T2._Fld27RRef,
| T2._Fld28RRef"+
// Отбрасываем итоговые записи с нулевым оборотом
" HAVING (CAST(SUM(T2._Fld29) AS NUMERIC(33, 8))) <> @P1) T1',
|N'@P1 numeric(1)', 0" // Параметр для проверки оборота на 0
Далее рассмотрим влияние использования агрегатов на изменения формируемого SQL-запроса платформой, при этом текст запроса на языке платформы в отчете останется прежним, но перед этим создадим и настроим агрегат.
В режиме конфигуратора перейдем в свойства регистра накопления "ДвиженияНоменклатуры" на закладку "Данные". Нажмем на кнопку "Агрегаты" для открытия конструктора агрегатов.
В конструкторе добавим новый агрегат для всех измерений регистра с периодичностью "Год" (вспомните, отчет будет формировать обороты в разрезе этой периодичности). Параметр "Использование" оставим без изменений. Обновим конфигурацию базы данных.
Этими действиями мы создали агрегат, который будет хранить итоговые записи с периодичностью "Год"(а не "Месяц", как это делает стандартный механизм итогов). Теперь нам нужно включить использование агрегатов в режиме 1С:Предприятие. Откроем стандартную утилиту управления итогами, вкладка "Агрегаты". Здесь нам нужно проделать следующие действия:
1. Включить режим агрегатов. При этом стандартный механизм итогов будет отключен.
2. Включить использование агрегатов. Не стоит путать этот параметр с предыдущим. Первый параметр устанавливает что будет использоваться платформой для виртуальной таблицы обороты - стандартная таблица итогов или таблицы агрегатов. Этот параметр фактически устанавливает доступность использования виртуальной таблицы оборотов при использовании агрегатов.
3. Перестроим агрегаты. Этим действием мы заполним таблицы агрегатов соответствующими настройкам агрегата записями по таблице движений регистра.
При перестроении агрегатов предлагается указать два параметра: максимальный относительный размер и минимальный эффект от перестроения (см. скриншот слева).
Первый параметр позволяет задать ограничение максимального размера таблицы агрегатов в процентах от таблицы движений. Если значение 0 - ограничений нет.
Второй параметр - это процент, на который требуется увеличить эффект старой сети при перестроении, если новая сеть делает больше эффект на значение "Минимальный эффект от перестроения %", то способ реально перестраивает сеть.
Агрегат создан, настроен и готов к использованию. Далее рассмотрим изменение SQL-запроса платформы при включенном агрегате.
Сторона СУБД
Выполним запрос отчета повторно. На этот раз платформа сформирует следующий SQL-запрос:
"SELECT
| T1.YearPeriod_, // Период (год)
| T1.Fld27RRef, // Номенклатура
| T1.Fld28RRef, // Склад
| T1.Fld29Turnover_ // КоличествоОборот
|FROM
| (SELECT
| T2.YearPeriod_ AS YearPeriod_, // Период (год)
| T2.Fld27RRef AS Fld27RRef, // Номенклатура
| T2.Fld28RRef AS Fld28RRef, // Склад
| CAST(SUM(T2.Fld29Turnover_) AS NUMERIC(38, 8))
| AS Fld29Turnover_ // Количество оборот
| FROM"+
// Получаем обороты из построенной
// таблицы агрегатов "_AccumRgAgg76h65",
// где оборот не равен 0
" (SELECT
| T3._Period AS YearPeriod_,
| T3._Fld27RRef AS Fld27RRef,
| T3._Fld28RRef AS Fld28RRef,
| CAST(T3._Fld29 AS NUMERIC(27, 2)) AS Fld29Turnover_
| FROM _AccumRgAgg76h65 T3 WITH(NOLOCK)
| WHERE (T3._Fld29 <> @P1)
|
| UNION ALL
|"+
// Получаем данные из таблицы новых оборотов
// в которой содержатся записи по новым движениям,
// сформированным после перестроения агрегатов
" SELECT
| T4._Period AS YearPeriod_, // Период (год)
| T4._Fld27RRef AS Fld27RRef,// Номенклатура
| T4._Fld28RRef AS Fld28RRef,// Склад
| CAST(SUM(T4._Fld29) AS NUMERIC(33, 8))
| AS Fld29Turnover_"+ // КоличествоОборот
// Данные получаем из таблицы
// новых оборотов "_AccumRgDl66"
" FROM _AccumRgDl66 T4 WITH(NOLOCK)"+
// Записи новых движений сгруппируем по всем измерениям,
// КоличествоОборот просуммируем.
" GROUP BY T4._Period,
| T4._Fld27RRef,
| T4._Fld28RRef"+
// Итоговый оборот по сгруппированным движениям не должен
// равен 0
" HAVING (CAST(SUM(T4._Fld29) AS NUMERIC(33, 8))) <> @P1
| ) T2
| GROUP BY T2.YearPeriod_,
| T2.Fld27RRef,
| T2.Fld28RRef"+
// Убираем записи с итоговым оборотом равным 0
" HAVING (CAST(SUM(T2.Fld29Turnover_)
| AS NUMERIC(38, 8))) <> @P1
| ) T1',
|N'@P1 numeric(1,0)', 0"
Если кратко, то запрос получает данные по оборотам из таблицы агрегата (ее мы заполнили при перестроении агрегата) и таблицы новых оборотов агрегата (в нее попадают новые обороты по регистру до перестроения или обновления агрегата).
Для лучшего понимания работы агрегатов разберем структуру таблиц базы данных, которые используются для их функционирования.
Если для оборотного регистра накопления создан хотя бы один агрегат, то обязательно будут созданы следующие таблицы:
1. Таблица настройки агрегатов регистра накопления.
Здесь сохраняются настройки агрегатов регистров накопления, которые мы установили в режиме 1С:Предприятия (режим агрегатов, использование агрегатов).
2. Таблица списка агрегатов регистра накопления.
Таблица содержит список агрегатов и их параметры (состав измерений, периодичность, использование и др.).
3. Таблица новых оборотов
Агрегаты не могут обновляться автоматически при выполнении движений по регистру, как это происходит в режиме итогов. Поэтому при выполнении движений/проведении документа новые обороты по регистру записываются в таблицу новых оборотов, а после при выполнении обновления/перестроения агрегатов переносятся в основную таблицу агрегатов. Состав таблицы зависит от структуры регистра и агрегатов.
4. Таблица буфера оборотов
Таблица буфера оборотов используется при обновлении агрегатов и имеет структуру, аналогичную таблице новых оборотов (см. выше). Если перестроение агрегатов формирует данные таблицы агрегатов заново, то обновление лишь переносит записи из таблицы новых оборотов в таблицу агрегатов.
Чтобы в момент обновления агрегатов обеспечить стабильную, параллельную работу пользователей и используется таблица буфера оборотов. В момент обновления агрегатов все записи из таблицы новых оборотов переносятся в таблицу буфера, после чего именно он используется для обновления агрегата. 
Если в этот момент пользователи записывают новые движения в регистр накопления, то они будут добавляться в таблицу новых оборотов и никак не повлияют на таблицу агрегатов. Они будут перенесены только при последующем обновлении агрегата.
5. Таблица статистики запросов
Агрегаты могут следить за запросами к базе данных, выполняемыми платформой в процессе работы пользователей. Результат этого - таблица статистики запросов.
Подробно останавливаться на ней мы не будем. Отмечу лишь, что собранная статистика используется платформой 1С:Предприятия для создания оптимальных агрегатов.
Эта возможность доступна в режиме 1С:Предприятия. Выгрузив оптимальные агрегаты в файл-описание формата XML, Вы сможете загрузить их в конструкторе агрегатов в режиме конфигуратора.
Оптимальные агрегаты нужно рассматривать как рекомендации платформы. Решение об использовании того или иного агрегата должен принимать разработчик.
6. Основная таблица агрегатов
Все пе
речисленные выше таблицы создаются всегда в единственном экземпляре для регистров накопления, использующих агрегаты. Для рассмотрения осталась последняя таблица - таблица агрегата регистра накопления, имеющая имя "AccunRg<ДопИмя>". В отличии от остальных таблиц, эта таблица создается отдельного для каждого агрегата регистра накопления. Сколько агрегатов - столько и таблиц.
Структура таблицы агрегата зависит от его настроек (периодичность, состав измерений). Например, так выглядит таблица с включенной периодичностью и составом полей из двух измерений (номенклатура и склад) (см. справа).
Если у агрегата отключить периодичность и убрать из состава одно измерение, то таблица агрегатов изменится следующим образом:
Назначение каждого поля таблицы легко понять, посмотрев расшифровку полей ранее рассмотренных таблиц.
Не была упомянута таблица "AccumRgAggDims", хранящая коды измерений агрегатов регистров накопления, т.к. в нашем случае она имеет мало значения. О ней Вы можете найти информацию самостоятельно.
Вернемся к запросу
В самом начале был представлен SQL-запрос платформы 1С:Предприятие 8.2 для получения оборотов по регистру "ДвиженияНоменклатуры" в разрезе лет, номенклатуры и складов. В запросе как-раз использовалась таблица агрегатов (получения уже сформированных агрегатов) и таблица новых оборотов (для получения данных по оборотам, еще не перенесенных в таблицу агрегатов).
За счет того, что запрос получает данные итоговых записей в разрезе лет, а не в разрезе месяцев (как это было бы при использовании стандартного механизма итогов), время выполнения запроса значительно сокращается, т.к. объем обрабатываемых данных значительно меньше.
Сравним SQL-запросы платформы для получения данных оборотов с использованием стандартного механизма итогов и при использования агрегатов.
Эффект
С помощью встроенной обработки создания документов в тестовой конфигурации были созданы 1.234.620 документов "Приходный ордер" и 1.161.714 документов "Расходный ордер". В общей сложности эти документы создали 16.131.357 записей движений в регистре "Движения номенклатуры".
Эти данные не покажут значительной разницы в производительности запросов, но заложенный принцип оптимизации должен быть понятен. В нашем примере среднее время выполнения запроса с использованием итогов составит 39.5 миллисекунд. Запрос же при использовании агрегатов выполнится в среднем за 22.9 миллисекунд. Абсолютные значения времени небольшие, но относительная разница существенная. SQL-запрос при использовании агрегатов выполнился быстрее на 42%. Согласитесь, разница существенная.
Основная причина ускорения времени выполнения запросов заключается в снижении обрабатываемого объема данных. Например за 23 года по 3 складам и 15 позиций номенклатуры стандартный механизм итогов создаст следующее количество записей в таблице итогов:
- 23 года * 12 месяцев * 3 склада * 15 позиций номенклатуры = 12420 итоговых записей
В случае же использования агрегата с периодичностью "Год" итоговые записей будет в 12 раз меньше:
- 23 года * 3 склада * 15 позиций номенклатуры = 12420 итоговых записей = 1035
Конечно, смысл использовать агрегаты появляется только в том случае, когда время выполнения запроса для получения данных оборотного регистра накопления будет заметно пользователям, а не только инструментам замера производительности.
Пример фактических планов выполнения запросов по итогам и агрегатам Вы можете посмотреть на следующем скриншоте.
Вместо заключения
Платформа 1С:Предприятие 8.2 позволяет значительно ускорить обращение к оборотным регистрам накопления за счет использования "собственных итогов", или агрегатов. Выше был продемонстрирован пример оптимизации за счет агрегатов и рассмотрен принцип их работы.
В примере показано ускорение выполнения итоговых оборотов по годам в разрезе номенклатуры и складов. Для этого был создан агрегат с периодичностью "Год" и составом измерений "Номенклатура" и "Склад". Этот агрегат является оптимальным для решения поставленной в начале статьи задачи.
Но если бы мы создали агрегат, например исключив из состава измерение "Номенклатура", то платформа бы не смогла его использовать при формировании отчета, так как он не содержит итогов в разрезе номенклатуры. В этом случае отчет формировался значительно медленнее (даже медленнее чем при включенном режиме итогов), т. к. использовалась бы только таблица движений. Именно поэтому так важно создать оптимальные агрегаты с правильной периодичностью и составом измерений. Последнее зависит от конкретной задачи.
И последний важный момент, на котором мы остановимся - это обновление и перерасчет агрегатов. Как упоминалось выше, если стандартные итоги могут обновляться автоматически при записи движений, то обновлять агрегаты разработчику нужно будет самостоятельно. Например, используя регламентное задания, запускаемое раз в сутки. Вот так будет выглядеть программный код для обновления агрегатов нашего регистра:
РегистрыНакопления.ДвиженияНоменклатуры.ОбновитьАгрегаты();
Выполнять эту операцию рекомендуется в моменты наименьшей нагрузки на сервер 1С:Предприятия.
Что дальше
На этом коротая серия статей о внутреннем устройстве регистров накопления закончена. Конечно, не все вопросы и нюансы были раскрыты. Вернемся к вопросам индексов и внутреннем устройстве других объектов платформы в последующих статьях.
Другие ссылки
- Регистры сведений 1С. Как это устроено
- Заметки по SQL: Срез последних - аналог запроса
- Индексы таблиц базы данных
- Регистры накопления. Структура хранения в базе данных
- Регистры накопления. Виртуальные таблицы. Часть №1: Обороты
-
Регистры накопления. Виртуальные таблицы. Часть №2: "Остатки" и "Остатки и обороты"
