На одном из проектов заказчика объём базы 1С:ERP достиг 16 ТБ, а регистр накопления «СебестоимостьТоваров» вырос до 4 ТБ и 2 млрд строк. При таких объёмах оптимизация перестала быть опцией и превратилась в обязательную задачу.

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

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

Для решения задачи использовалось секционирование (партиционирование) таблиц на уровне MS SQL Server. Но, как оказалось, у 1С и секционирования сложные отношения. 

Меня зовут Владимир Андрейков, я руководитель группы разработки в GRI. Эта статья — разбор практического кейса из проекта заказчика. Она будет полезна тем, кто работает с крупными внедрениями 1С:ERP и упирается в ограничения SQL Server при больших объёмах данных.

Схема секционирования: квартальные файловые группы + помесячные секции

При реализации секционирования учитывались два ключевых ограничения: объём данных и характер запросов. 

С учётом этих факторов была использована двухуровневая схема:

• Каждый квартал — в своей файловой группе.
  Такой подход позволяет размещать архивные кварталы на более медленных дисковых подсистемах или даже отключать их физически.

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

Схема границ и функция секционирования были реализованы вручную средствами T-SQL. Однако основной сложностью стала не декларация структуры, а наполнение: перенос 2 млрд исторических строк в секционированную модель оказался нетривиальной задачей.

Даже операции уровня ALTER TABLE ... SWITCH в ряде случаев выполнялись часами, что делало классический подход непригодным для «живой» системы. Именно здесь начали проявляться первые неожиданные ограничения.

Подводный камень №1: datetime2 и неявное преобразование

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

На уровне наблюдений всё выглядело корректно, но запросы отчётов продолжали сканировать все секции. Диагностика с помощью
SET STATISTICS IO и анализа плана выполнения показала ключевую проблему: partition pruning фактически не работал.

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

• в стандартных таблицах регистров 1С поле _Period имеет тип datetime2(0) с точностью до секунд;

• параметры, которые передаёт платформа через sp_executesql, передаются как datetime2(3) с точностью до миллисекунд. 

Именно здесь проявился ключевой эффект. SQL Server выполняет неявное приведение границ поиска к типу поля таблицы. А при секционировании по _Period это мешает partition pruning: оптимизатор не понимает, что можно обратиться только к одной секции, и обходит все секции.

Разница в скорости между ручным SQL-запросом с явным указанием datetime2(0) и штатным запросом от 1С могла составлять одну секунду вместо трёх минут.

Устранение проблемы

Тип поля _Period в таблицах регистра «СебестоимостьТоваров» был изменён с datetime2(0) на datetime2(3). При этом не потребовались ни отказ от виртуальных таблиц, ни переписывание запросов — тип в таблице был приведён к тому типу, который передаёт платформа.

После этого неявное преобразование исчезло, и секционирование начало работать корректно.

Важно: такая операция требует блокировки таблицы и перестройки всех связанных индексов. Для таблиц объёмом порядка 2 млрд строк её рекомендуется выполнять в периоды минимальной нагрузки.

Подводный камень №2: общий реквизит-разделитель

Следующее ограничение проявилось уже на уровне индексов и структуры доступа к данным.

В типовых конфигурациях 1С:ERP широко используется механизм общего реквизита-разделителя (например, «Организация» или «ОбластьДанныхОсновныеДанные»). Платформа автоматически добавляет этот реквизит первым полем во все индексы таблицы. 

Казалось бы, это логичный механизм изоляции данных. Но для секционирования это катастрофа:

• Первое поле индекса — разделитель, а не период.

• Секционирование выполняется по _Period, а индекс начинается с другого поля.

В итоге даже при идеальном партицировании по дате многие запросы всё равно сканировали несколько секций, потому что доступ к данным шёл через индекс, в котором период не на первом месте.

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

Но в связке с секционированием это стало ограничением: индексная структура начинала расходиться с моделью партиционирования, и оптимизатор снова терял возможность эффективно работать с секциями. То есть, возникал конфликт между прикладным механизмом изоляции и физической моделью хранения данных. 

В данном регистре разграничение доступа было реализовано на уровне прикладной логики. После отключения разделителя были перестроены кластеризованные индексы — и только после этого секционирование наконец «проснулось».

Как это реализовывалось технически

На практике вся миграция заняла около 48 часов активной работы и ещё примерно 1,5 недели фоновой обработки данных. Процесс выполнялся поэтапно, с последовательной проверкой результатов на каждом этапе. 

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

На этом этапе проверялось соответствие схемы секционирования характеру запросов и распределению данных между файловыми группами.

Далее на тестовой копии было проверено изменение типа _Period с datetime2(0) на datetime2(3). После подтверждения отсутствия регрессий и проблем с выборками изменения были перенесены в прод.

Отдельным шагом стало отключение общего реквизита-разделителя для регистра на уровне конфигурации 1С — как часть приведения физической модели данных в соответствие с моделью секционирования в SQL Server.

Фоновое копирование вместо SWITCH PARTITION

Классическая схема миграции через ALTER TABLE ... SWITCH PARTITION в нашем случае оказалась неприменимой. Основные ограничения — длительная монопольная блокировка и необходимость строгой подготовки партиций.

Для объёма в 2 млрд строк простой системы мог составлять десятки часов. В этих условиях применялась следующая схема:

1. Были созданы пустые копии таблиц регистра с целевой структурой (уже секционированные, с нужными индексами).

2. Было организовано фоновое копирование данных из исходных таблиц в новые (по 100–200 тысяч записей). Этот процесс занял около полутора недель и практически не влиял на основную работу системы, лишь незначительно увеличивая нагрузку на диск и транзакционный лог.

3. После завершения копирования операции записи в регистр были временно остановлены (в ночное окно), после чего были перенесены накопившиеся изменения и выполнена замена таблиц.

В результате время монопольной блокировки базы на этапе подмены составило не более 30 минут вместо десятков часов при классическом SWITCH.

Такой подход потребовал дополнительного дискового пространства объёмом около 4 ТБ, однако позволил избежать длительного простоя системы.

Итог

После завершения работ физический объём базы остался прежним — 16 ТБ, но изменилось поведение системы под нагрузкой.

Ключевой эффект проявился не в «ускорении всего», а в перераспределении нагрузки и устранении неэффективных сканирований.

В результате:

• время выполнения отчётов за текущий месяц сократилось с 2-3 минут до 3-5 секунд;

• расчёт себестоимости перестал выходить за ночное окно;

• нагрузка на дисковую подсистему стала прогнозируемой.

Вывод

Секционирование в 1С:ERP — рабочий инструмент, но его эффективность определяется не самим фактом partitioning, а согласованием трёх слоёв: типов данных, структуры индексов и поведения платформы.

Для корректной работы секционирования критическими оказались два фактора: несовпадение точности datetime2 и влияние общего реквизита-разделителя.

После их устранения секционирование перестало быть «теоретически правильной схемой» и стало работающим инструментом для обработки базы объёмом 16 ТБ.