На одном из проектов заказчика объём базы 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 млрд строк простой системы мог составлять десятки часов. В этих условиях применялась следующая схема:
Были созданы пустые копии таблиц регистра с целевой структурой (уже секционированные, с нужными индексами).
Было организовано фоновое копирование данных из исходных таблиц в новые (по 100–200 тысяч записей). Этот процесс занял около полутора недель и практически не влиял на основную работу системы, лишь незначительно увеличивая нагрузку на диск и транзакционный лог.
После завершения копирования операции записи в регистр были временно остановлены (в ночное окно), после чего были перенесены накопившиеся изменения и выполнена замена таблиц.
В результате время монопольной блокировки базы на этапе подмены составило не более 30 минут вместо десятков часов при классическом SWITCH.
Такой подход потребовал дополнительного дискового пространства объёмом около 4 ТБ, однако позволил избежать длительного простоя системы.
Итог
После завершения работ физический объём базы остался прежним — 16 ТБ, но изменилось поведение системы под нагрузкой.
Ключевой эффект проявился не в «ускорении всего», а в перераспределении нагрузки и устранении неэффективных сканирований.
В результате:
время выполнения отчётов за текущий месяц сократилось с 2-3 минут до 3-5 секунд;
расчёт себестоимости перестал выходить за ночное окно;
нагрузка на дисковую подсистему стала прогнозируемой.
Вывод
Секционирование в 1С:ERP — рабочий инструмент, но его эффективность определяется не самим фактом partitioning, а согласованием трёх слоёв: типов данных, структуры индексов и поведения платформы.
Для корректной работы секционирования критическими оказались два фактора: несовпадение точности datetime2 и влияние общего реквизита-разделителя.
После их устранения секционирование перестало быть «теоретически правильной схемой» и стало работающим инструментом для обработки базы объёмом 16 ТБ.