Журнал "Information Security/ Информационная безопасность" #3, 2026

Но по мере роста нагрузки и числа пользователей начинают проявляться другие проблемы: сложнее контролиро- вать доступ к данным, усложняется ана- лиз происходящего в системе, увеличи- вается риск сбоев при пиковых опера- циях. Эти задачи уже не решаются на уровне прикладной логики – они напря- мую зависят от того, как ведет себя СУБД. Все дело в характере нагрузки, кото- рую создает 1С. Значительная часть SQL-запросов формируется самой плат- формой, поэтому СУБД регулярно стал- кивается с большим количеством слож- ных однотипных конструкций. В резуль- тате нагрузка заметно отличается от типичных сценариев использования уни- версальных СУБД. Где начинает ломаться PostgreSQL При такой нагрузке стандартный Post- greSQL, конечно, продолжает работать, но его поведение становится менее предсказуемым. Одна из первых проблем – планиров- щик запросов. Именно он определяет, как будут выполняться сложные запросы с соединениями, агрегатами и условиями доступа. При сложных соединениях и большом количестве условий он может некорректно оценивать объем данных и выбирать неоптимальный план выпол- нения. В результате один и тот же запрос в разных условиях дает разное время выполнения. Заметно проявляется влияние вре- менных таблиц. Их массовое созда- ние – характерная черта 1С, оно при- водит к росту нагрузки на системный каталог, увеличению числа служеб- ных операций и дополнительным бло- кировкам. Со временем это сказыва- ется на общей производительности системы, особенно при пиковых нагрузках. Проблемы возникают и со статисти- кой. Для корректной работы планиров- щика она должна быть актуальной и достаточно точной, но при большом количестве временных объектов и изме- няющихся данных поддерживать ее в таком состоянии становится сложно. Результат – усиливается нестабиль- ность планов выполнения. Наконец, начинают проявляться ограничения с точки зрения контроля и анализа. Стандартные средства логи- рования дают общий обзор, но не все- гда позволяют понять, какие именно запросы формируют нагрузку и как они связаны между собой. При боль- шом количестве временных таблиц и динамических запросов картина ста- новится неполной. В результате система формально работает, но требует все больше ручной настройки и внимания со стороны адми- нистраторов. Именно в этой точке воз- никает необходимость менять поведение СУБД, а не только параметры ее настройки. При этом, с одной стороны, система требует стабильной производительности – особенно в регламентных операциях и отчетности. С другой – необходимо сохранять механизмы контроля: разгра- ничение доступа, аудит действий, воз- можность разбирать инциденты. Про- блема в том, что эти требования начи- нают противоречить друг другу. Напри- мер, ограничение доступа на уровне записей увеличивает сложность запро- сов и нагрузку на планировщик. Под- робный аудит увеличивает объем логи- рования и нагрузку на систему. При высокой активности это напрямую влияет на время выполнения операций. В результате на практике возникают компромиссы. Часть механизмов упро- щается, часть отключается, часть пере- носится на уровень приложений. То есть одной только перенастройки параметров PostgreSQL уже становится недостаточ- но. Чтобы избежать таких компромиссов, требуется изменить саму модель работы СУБД под характер нагрузки 1С. Появление специализированных СУБД Ответом на эту проблему стали спе- циализированные сборки PostgreSQL, адаптированные под работу с 1С. Их задача – не просто ускорить отдельные операции, а изменить поведение СУБД в типичных для 1С сценариях. В спе- циализированных сборках изменения не сводятся к отдельным оптимиза- циям, в них дорабатываются сразу несколько уровней: ядро, планиров- щик, механизмы работы со статисти- кой и набор инструментов админи- стрирования. Один из примеров такого подхода – СУБД Tantor Postgres в редакции Special Edition 1 . В этой сборке изменения направ- лены на те узкие места, которые про- являются именно в системах 1С. Первое, на что обращают внима- ние, – работа с временными таблица- ми. В Tantor Postgres для 1С этот механизм переработан: физическое размещение таблиц может отклады- ваться до момента фактического использования, часть метаданных переносится в память, сокращается количество синхронизаций с диском. В результате снижается нагрузка на систему при типичных сценариях, где временные таблицы создаются и уда- ляются постоянно. Следующий блок – планировщик запросов. В специализированной СУБД улучшается оценка селективности, дора- батывается работа с многоколоночными индексами, добавляются преобразова- ния запросов, которые позволяют выпол- нять их более эффективно. В частности, оптимизируются конструкции, характер- ные для 1С, включая обращения к вир- туальным таблицам и использование ограничений доступа. Это дает более стабильное время выполнения и снижает зависимость от конкретных условий нагрузки. Заметно дорабатывается работа со статистикой. Для корректной работы планировщика важно, чтобы данные о распределении значений были актуаль- ными и точными. В Tantor Postgres для 1С появляются механизмы автоматиче- 64 • ТЕХНОЛОГИИ Разбор надежности и безопасности систем 1С на базе СУБД Tantor Postgres SE для 1C абота систем на базе 1С:Предприятие традиционно обсужда- ется через призму производительности. Быстрее выполняются запросы, быстрее закрывается месяц, меньше задержек у пользователей – именно эти критерии чаще всего используют- ся при оценке СУБД под капотом 1C. Р Вадим Яценко, генеральный директор “Тантор Лабс” Фото: Tantor Labs 1 https://tantorlabs.ru/tantor-se-1c