Что быстрее в 1С: регистр сведений или регистр накопления

Вопрос «что быстрее — регистр сведений или регистр накопления» некорректен без уточнения операции: эти объекты спроектированы под разные задачи, и скорость зависит от того, что именно вы делаете — пишете движения документом, читаете срез последних, считаете остатки или строите отчёт. В типовых сценариях запись в регистр сведений обычно дешевле, а чтение агрегированных данных (остатки, обороты) быстрее из регистра накопления за счёт специальных таблиц итогов.

Регистр сведений хранит строки «измерения + ресурсы» без агрегации: платформа не поддерживает для него итоговые таблицы, поэтому запись — это простая вставка или обновление строк. Регистр накопления вида «Остатки» при записи дополнительно обновляет таблицу итогов, что делает запись дороже, но зато чтение остатков выполняется почти мгновенно даже на больших объёмах.

Ниже разобраны механики обеих структур, типовые узкие места и критерии выбора, чтобы вы могли принимать решение на основе архитектуры, а не интуиции.

Как устроена запись и где теряется время

При проведении документа по регистру сведений платформа выполняет вставку или обновление строк в одной физической таблице. Если регистр подчинён регистратору, добавляется отбор по регистратору; если независимый периодический — контролируется уникальность по измерениям и периоду. Никаких дополнительных вычислений не происходит, поэтому стоимость записи близка к стоимости обычной вставки в таблицу СУБД.

Регистр накопления вида «Остатки» работает иначе. Помимо таблицы движений платформа поддерживает таблицу итогов: при записи каждое движение изменяет накопленные остатки по комбинации измерений. Это дополнительные операции на уровне СУБД, блокировки итоговых записей и, как следствие, более высокая стоимость проведения, особенно при параллельной работе пользователей по одним и тем же измерениям (например, по одному складу или номенклатуре).

Практический вывод: если ваша задача — массовая запись фактов (логи, статусы, история изменений, курсы валют), регистр сведений будет заметно быстрее и дешевле по блокировкам. Переносить такие данные в регистр накопления только ради единообразия — распространённая архитектурная ошибка.

Скорость чтения: срез последних против остатков

Для периодического регистра сведений платформа предоставляет виртуальные таблицы «СрезПервых» и «СрезПоследних». На современных версиях платформы срез последних может рассчитываться быстро за счёт специального механизма, но на больших таблицах с множеством измерений и частыми записями он всё равно требует группировки по измерениям с поиском максимального периода — это дороже, чем чтение готового итога.

Регистр накопления «Остатки» отдаёт остатки через виртуальную таблицу «Остатки» практически мгновенно: данные уже агрегированы и лежат в таблице итогов. Обороты за период также читаются из итоговых таблиц, если включено использование итогов. Именно поэтому отчёты по складам, взаиморасчётам и деньгам строят на регистрах накопления, а не на выборках из регистров сведений с последующей свёрткой в запросе.

Если вы пытаетесь хранить «остатки» как ресурс регистра сведений и пересчитывать их запросом — вы получите худший из вариантов: медленное чтение и ручную поддержку корректности данных. Это главный сценарий, где регистр накопления выигрывает на порядки.

Роль индексов, измерений и режимов итогов

Скорость обоих регистров критически зависит от состава измерений. Каждое измерение попадает в индексы: чем больше измерений и чем выше их селективность, тем тяжелее запись и тем больше таблица. Частая ошибка — добавлять в измерения регистра накопления «лишние» аналитики «про запас»: каждая такая аналитика раздувает таблицу итогов и замедляет проведение всех документов, которые пишут в этот регистр.

Для регистра сведений важно свойство «Ведущее» у измерений и корректная периодичность. Периодичность «В пределах секунды» или «По позиции регистратора» увеличивает объём данных; если достаточно периодичности «В пределах дня», не завышайте её. Для независимых регистров сведений проверяйте, что запросы к срезу последних используют отборы по измерениям — без отборов срез превращается в полное сканирование с группировкой.

Для регистров накопления дополнительно влияет режим проведения документа. Оперативное проведение требует актуальных итогов на текущую дату и чувствительно к «рассчитанным итогам». Если документы проводятся задним числом, итоги после этой даты становятся неактуальными, и чтение остатков начинает дочитывать движения — скорость падает до пересчёта итогов.

Практический замер: как сравнить скорость в своей базе

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

Методика проста: выберите типовую операцию (проведение документа, получение остатка, срез последних), выполните её в цикле на копии базы, зафиксируйте среднее время. Затем измените один фактор — состав измерений, режим итогов, отбор в запросе — и повторите. Сравнивать нужно одинаковые операции: «запись в регистр сведений против записи в регистр накопления» — корректный тест, а «запись против чтения остатков» — нет.

1. 1
   Разверните копию рабочей базы и заполните её данными, близкими по объёму к боевым.
2. 2
   Определите 2–3 типовые операции: проведение документа, чтение остатков, срез последних.
3. 3
   Выполните каждую операцию в цикле не менее 10–20 раз, замеряя время через ТекущаяУниверсальнаяДатаВМиллисекундах.
4. 4
   Зафиксируйте среднее значение, измените один параметр структуры или запроса и повторите замер.
5. 5
   Сравните результаты и примите решение по архитектуре на основе цифр, а не предположений.

Начало = ТекущаяУниверсальнаяДатаВМиллисекундах();
Для Сч = 1 По 100 Цикл
    // тестируемая операция
КонецЦикла;
Длительность = (ТекущаяУниверсальнаяДатаВМиллисекундах() - Начало) / 100;

Когда какой регистр выбирать

Критерий выбора — природа данных, а не скорость сама по себе. Регистр сведений предназначен для хранения фактов и настроек в разрезе измерений: курсы валют, цены номенклатуры, статусы объектов, соответствия значений. Здесь не нужны итоги, и платная запись регистра накопления была бы пустой тратой ресурсов.

Регистр накопления предназначен для количественных показателей, которые складываются и вычитаются: товары на складах, деньги, взаиморасчёты, остатки на счетах. Попытка заменить его регистром сведений с «текущим остатком» в ресурсе приводит к проблемам конкурентной записи: два пользователя, одновременно меняющие остаток по одной номенклатуре, перезапишут значения друг друга. Регистр накопления решает это естественно — движения независимы, а итог считает платформа.

Типичные ошибки и проверка результата

Самая дорогая ошибка — избыточные измерения в регистре накопления «Остатки». Каждое измерение умножает количество строк в таблице итогов; на больших базах это приводит к заметному замедлению проведения и росту блокировок. Вторая ошибка — чтение остатков без отборов по измерениям в запросах: виртуальная таблица «Остатки» с пустыми параметрами на большой базе возвращает огромный набор данных.

Третья ошибка — использование среза последних регистра сведений в цикле или в соединении без отбора. Если вам нужно значение по конкретному ключу, передавайте отбор в параметры виртуальной таблицы, а не фильтруйте результат после соединения. Четвёртая — хранение в регистре сведений данных, которые должны суммироваться, с последующей «сборкой» итогов в запросах: это медленнее и сложнее в поддержке, чем штатный регистр накопления.

FAQ