Регистры накопления. Агрегаты в оборотных регистрах

24.05.19

Разработка - Механизмы платформы 1С

Описание механизма агрегатов оборотных регистров накопления для платформы 1С 8.2. Рассмотрение хранения и принципа использования агрегатов платформой на стороне СУБД.

О регистрах накопления

В нескольких статьях представлены основные сведения о внутреннем устройстве регистров накопления, о SQL-запросах платформы при работе с ними и их изменение в зависимости от настроек регистра. Подробно описана работа платформы с разными типами регистров (остатков и накопления), а также принцип действия агрегатов.

Материалы созданы во времена платформы 8.2, поэтому некоторые моменты могут быть уже не актуальными, но основные принципы работы остались неизменными.

 
 Это информация из старого блога DevelPlatform.ru

Конкретно в этой статье речь идет о механизме агрегатов оборотного регистра накопления в базе данных. Все примеры из публикации Вы можете найти на GitHub.

Предисловие

В предыдущих статьях мы говорили о структуре хранения регистров накопления в базе данныхработе платформы с виртуальной таблицей "Обороты", также "Остатки" и "Остатки и обороты" этих регистров в зависимости от настроек хранения итогов. Все эксперименты проводились на тестовой конфигурации, содержащей два регистра накопления видов "Остатки" и "Обороты" (подробнее см. в предыдущих статьях).

Сегодня в статье рассмотрим действия платформы при работе с агрегатами оборотных регистров накопления.

Что это за "зверь"?

В предыдущих статьях были рассмотрены вопросы хранения регистров накопления в SQL-базе данных, а также принцип работы платформы с виртуальными таблицами регистров и формируемые при этом платформой SQL-запросы:

Сегодня мы коснемся возможности задействовать механизм произвольных агрегатов для регистров накопления с видом "Обороты". С их помощью можно значительно ускорить формирование отчетов по регистрам накопления в тех случаях, когда количество записей в регистре составляет сотни тысяч, миллионы и более.

Агрегаты позволяют создать заранее рассчитанные данные для формирования отчетов на подобие итогов регистров накопления. Последние рассчитываются платформой автоматически (при условии включения использования итогов для регистра) в отличии от агрегатов. Но для чего нужны агрегаты, если подобную задачу выполняют итоги?

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

Общую информацию об агрегатах оборотных регистров накопления Вы можете посмотреть на официальном сайте. Далее в статье мы рассмотрим создание и настройку агрегатов, а также принцип работы платформы с ними на стороне базы данных. Для примеров будет использоваться тестовая конфигурация, используемая в перечисленных выше статьях.

Создание и настройка

Пользователю понадобился отчет, показывающий обороты номенклатуры в разрезе складов по годам. Вот пример сформированного отчета:

Ничего сложного в запросе, получающем данные для отчета, нет. Используя виртуальную таблицу оборотов мы получаем общее количество оборота по годам. Вот текст запроса отчета:

"ВЫБРАТЬ
|  ДвиженияНоменклатурыОбороты.ПериодГод,
|  ДвиженияНоменклатурыОбороты.Номенклатура,
|  ДвиженияНоменклатурыОбороты.Склад,
|  ДвиженияНоменклатурыОбороты.КоличествоОборот
|ИЗ
|  РегистрНакопления.ДвиженияНоменклатуры.Обороты(,
|                                                 , 
|                                                 Авто
|                                                 ,) 
|                   КАК ДвиженияНоменклатурыОбороты" 

В одной из предыдущих статей мы уже рассматривали какой 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С:Предприятия.

Что дальше

На этом коротая серия статей о внутреннем устройстве регистров накопления закончена. Конечно, не все вопросы и нюансы были раскрыты. Вернемся к вопросам индексов и внутреннем устройстве других объектов платформы в последующих статьях.

Другие ссылки

платформа регистры накопления SQL-запросы внутреннее устройство обороты агрегаты

См. также

Поинтегрируем: сервисы интеграции – новый стандарт или просто коннектор?

Обмен между базами 1C Администрирование СУБД Механизмы платформы 1С Платформа 1С v8.3 Бесплатно (free)

В платформе 8.3.17 появился замечательный механизм «Сервисы интеграции». Многие считают, что это просто коннектор 1С:Шины. Так ли это?

11.03.2024    3561    dsdred    48    

66

Как готовить и есть массивы

Механизмы платформы 1С Платформа 1С v8.3 Бесплатно (free)

Все мы используем массивы в своем коде. Это один из первых объектов, который дают ученикам при прохождении обучения программированию. Но умеем ли мы ими пользоваться? В этой статье я хочу показать все методы массива, а также некоторые фишки в работе с массивами.

24.01.2024    5032    YA_418728146    25    

62

Планы обмена VS История данных

Обмен между базами 1C Механизмы платформы 1С Платформа 1С v8.3 Бесплатно (free)

Вы все еще регистрируете изменения только на Планах обмена и Регистрах сведений?

11.12.2023    6160    dsdred    36    

110

1С-ная магия

Механизмы платформы 1С Бесплатно (free)

Язык программирования 1С содержит много нюансов и особенностей, которые могут приводить к неожиданным для разработчика результатам. Сталкиваясь с ними, программист начинает лучше понимать логику платформы, а значит, быстрее выявлять ошибки и видеть потенциальные узкие места своего кода там, где позже можно было бы ещё долго медитировать с отладчиком в поисках источника проблемы. Мы рассмотрим разные примеры поведения кода 1С. Разберём результаты выполнения и ответим на вопросы «Почему?», «Как же так?» и «Зачем нам это знать?». 

06.10.2023    18196    SeiOkami    46    

116

Дефрагментация и реиндексация после перехода на платформу 8.3.22

Механизмы платформы 1С Платформа 1С v8.3 Бесплатно (free)

Начиная с версии платформы 8.3.22 1С снимает стандартные блокировки БД на уровне страниц. Делаем рабочий скрипт, как раньше.

14.09.2023    11766    human_new    27    

72

Валидация JSON через XDTO (включая массивы)

WEB-интеграция Универсальные функции Механизмы платформы 1С Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

При работе с интеграциями рано или поздно придется столкнуться с получением JSON файлов. И, конечно же, жизнь заставит проверять файлы перед тем, как записывать данные в БД.

28.08.2023    8555    YA_418728146    6    

139

Внешние компоненты Native API на языке Rust - Просто!

Механизмы платформы 1С Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Внешние компоненты для 1С можно разработывать очень просто, пользуясь всеми преимуществами языка Rust - от безопасности и кроссплатформенности до удобного менеджера библиотек.

20.08.2023    6195    sebekerga    54    

93

Все скопируем и вставим! (Буфер обмена в 1С 8.3.24)

Механизмы платформы 1С Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Рассмотрим новую возможность 8.3.24 и как её можно эффективно использовать

27.06.2023    15524    SeiOkami    31    

103
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. user848614 27.05.19 17:13 Сейчас в теме
Спасибо за статью, интересно.
Замечание: 6. Основная таблица агрегатов. Не увидел разницу в картинках.
YPermitin; +1 Ответить
2. пользователь 27.05.19 20:02
(1) спасибо на добром слове.

Да, и правда так. При вставке ошибся и вставил один скриншот дважды. Исправил, спасибо что заметили.
3. alex1487 07.11.19 14:54 Сейчас в теме
Подскажите в какой момент записи в Таблице новых оборотов удаляются?
4. androidT1C 76 16.07.20 09:58 Сейчас в теме
(3) При обновлении Агрегатов. Записи переносятся из таблицы новых оборотов в таблицу агрегата.
5. androidT1C 76 16.07.20 10:01 Сейчас в теме
Тыкаюсь с агрегатами и замечаю такое поведение 1С:
- либо таблица оборотов
- либо агрегаты
Т.е. при включении агрегатов физически очищается таблица оборотов. При выключении - таблица агрегата.
Получается 1С не оставила возможность сочетания таблица оборотов + агрегаты.
Я прав?
Тогда, как правило, придется первым агрегатом делать дубль таблицы оборотов. Странно.
6. Denic_01 46 17.10.23 08:39 Сейчас в теме
Пытаюсь включить агрегаты на некоем регистре на большой базе.
Создаю в конфигураторе один простой агрегат.
Ничего особенного не делаю, никаких ограничений и тд не указываю - просто включаю, нажимаю перестроить.
Строится множество агрегатов, такое ощущение что все возможные комбинации, занимает, конечно, огромное место и по времени сутки другие.

Выгрузил CF файл, создал пустую файловую базу, пробую все тоже самое делать на ней - агрегаты создаются как надо т.е. один как я указал.

Вопрос заключается в том: почему игнорируются настройки заданные в конфигураторе на "основной" базе, может кто сталкивался ?
Оставьте свое сообщение