При работе с крупными базами данных на платформе 1С:Предприятие, особенно в файловом варианте, администраторы и разработчики часто прибегают к процедуре управления итогами. Однако нередко возникает ситуация, когда после долгого процесса пересчета итогов через Тестирование и исправление ожидаемого «взрывного» роста скорости в отчетах не наблюдается. Разберем детально, как устроены итоги в 1С, на что именно влияет их расчет и какие еще факторы замедляют работу тяжелых баз.
Для начала проанализируем, как 1С хранит данные в регистрах накопления. Физически в базе данных (будь то .1CD или таблицы SQL) существуют две основные структуры для каждого регистра:
Важно понимать, что в системе существует понятие текущих итогов. Они хранятся на фиктивную дату 01.01.3999. Когда мы выполняем запрос к виртуальной таблице Остатки без указания конкретной даты, платформа обращается именно к этой таблице актуальных значений. Эти итоги поддерживаются системой автоматически при проведении каждого документа, независимо от того, до какого периода рассчитаны «обычные» ежемесячные итоги. Именно поэтому, когда мы делаем запрос следующего вида:
ВЫБРАТЬ
ТоварыНаСкладахОстатки.Склад,
ТоварыНаСкладахОстатки.Номенклатура,
ТоварыНаСкладахОстатки.КоличествоОстаток
ИЗ
РегистрНакопления.ТоварыНаСкладах.Остатки КАК ТоварыНаСкладахОстатки
Мы не видим разницы в производительности до и после пересчета. Система в обоих случаях просто берет готовые цифры из таблицы актуальных итогов. Разница в 2-3%, которую заметил автор темы, является погрешностью измерений или результатом очистки индексов во время процедуры ТИ.
Рассмотрим ситуацию, когда запрос выполняется на конкретную дату в прошлом, например, на 01.01.2018. Здесь алгоритм работы платформы меняется. Система не может просто взять данные на 3999 год. Она ищет ближайшую точку рассчитанных итогов.
Выясним, почему первый запрос после пересчета может выполняться долго (например, 109 секунд), а второй — мгновенно (0.3 секунды). Это классическое проявление работы кеширования. При первом обращении операционная система и СУБД считывают данные с жесткого диска в оперативную память. Файловая база размером 25 ГБ создает огромную нагрузку на дисковую подсистему. При повторном запросе данные уже находятся в кеше Windows, и процессор обрабатывает их почти мгновенно.
Проанализируем поведение системы при запросе на дату. Если итоги рассчитаны по 30.06.2018, а мы просим остатки на 01.01.2018, система берет итоги на начало января 2018 года. Если же итоги были рассчитаны только по 2015 год, системе пришлось бы брать итоги 2015-го и прибавлять к ним все движения за 3 года, либо «отматывать» назад от актуальных итогов 3999 года, вычитая движения. Чем ближе дата запроса к точке рассчитанных итогов, тем меньше записей из таблицы движений нужно перелопатить системе.
Главная польза от поддержания актуального периода рассчитанных итогов заключается в ускорении записи, то есть проведения документов. Разберем, почему это происходит:
Важный нюанс: если в базе случайно окажется документ с некорректной датой (например, 01.01.0001 или далеко в будущем), механизм итогов начнет работать крайне неэффективно, пытаясь просчитать огромный временной интервал. Пересчет итогов помогает выявить и локализовать такие ошибки.
Ситуация, когда файловая база достигает размера 25 ГБ, является критической. Рассмотрим основные риски:
.1CD) ограничивает размер данных одной таблицы (включая индексы) порогом, близким к 4 ГБ. Если таблица движений крупного регистра (например, ПартииТоваровНаСкладах) превысит этот предел, база просто перестанет работать на запись.Для того чтобы реально ускорить работу базы в подобных условиях, одних только итогов недостаточно. Выделим основные шаги:
.1CD и ускорит работу с регистрами сведений и справочниками.Подводя итог, можно сказать: расчет итогов — это гигиеническая процедура, которая поддерживает стабильность проведения документов и скорость формирования исторических отчетов. Она не является «волшебной кнопкой» для ускорения чтения текущих остатков, так как архитектура 1С уже оптимизирована для этой задачи через механизм актуальных итогов.