Ограничение доступа на уровне записей (RLS) традиционно считается одним из главных «узких мест» в производительности крупных информационных баз на платформе «1С:Предприятие». В стандартном режиме RLS СУБД вынуждена динамически дописывать сложные условия к каждому SQL-запросу, что приводит к неоптимальным планам запросов, зависанию отчетов и регулярным взаимоблокировкам. Чтобы решить эту проблему, разработчики фирмы «1С» внедрили новый механизм — производительный (универсальный) режим ограничения доступа.
В этой статье мы подробно разберем, как устроен этот механизм изнутри, в чем его отличие от классического RLS, как правильно выполнить переход и стоит ли опасаться задержек в обновлении прав пользователей при оперативной работе.
Для того чтобы понять преимущества нового режима, проанализируем, как работают оба механизма на уровне взаимодействия платформы «1С» и СУБД.
1. Стандартный (старый) режим RLS
При использовании стандартного режима RLS условия ограничения доступа накладываются динамически в момент выполнения любого запроса к базе данных. Например, если у пользователя есть доступ только к организации «Торговый дом», то при формировании отчета по продажам платформа автоматически допишет к SQL-запросу конструкцию вида ГДЕ Организация = &РазрешеннаяОрганизация (или более сложные соединения, если ограничение идет по группам доступа физических лиц, контрагентов, складов).
Если ограничений несколько и они используют иерархию или сложные связи, итоговый SQL-запрос превращается в огромную конструкцию со множеством левых соединений (LEFT JOIN) и подзапросов. СУБД (особенно PostgreSQL на крупных базах данных) не справляется с построением эффективного плана выполнения такого запроса. В результате элементарный отчет или динамический список начинает открываться минутами, загружая процессор сервера базы данных на 100%.
2. Производительный (универсальный) режим RLS
Философия производительного режима RLS кардинально отличается. Вместо того чтобы вычислять права пользователя «на лету» в каждом запросе, система делает это предварительно (априори). На основе настроек прав и групп доступа система заранее вычисляет, к каким именно объектам (документам, элементам справочников) у каждого пользователя есть доступ.
Результаты этого расчета кэшируются и сохраняются в специальных служебных регистрах сведений в виде так называемых «Ключей доступа». При выполнении запроса к СУБД больше не нужно связывать таблицы документов с таблицами настроек прав, иерархией подразделений или группами контрагентов. Платформа делает одно максимально простое и быстрое соединение с таблицей ключей доступа по идентификатору объекта и текущего пользователя. Для СУБД такой запрос является элементарным, план его выполнения строится мгновенно, а скорость чтения данных увеличивается в десятки и сотни раз.
Давайте заглянем под капот программного кода «1С:Библиотеки стандартных подсистем» (БСП) и выясним, как реализуется этот механизм.
В ролях конфигурации разработчики используют специальные шаблоны ограничений. Для обеспечения совместимости со старым и новым режимами в коде шаблонов применяется условная компиляция на уровне макросов платформы:
#Если &ОграничениеДоступаНаУровнеЗаписейУниверсально #Тогда
#ДляОбъекта("")
#Иначе
#ПоЗначениям("Справочник.Организации", "", "", "", "", "", "", "", "", "", "", "", "", "")
#КонецЕсли
Если в системе включена константа ОграничиватьДоступНаУровнеЗаписейУниверсально, то отрабатывает лаконичный шаблон #ДляОбъекта. Он просто проверяет наличие связи объекта с таблицей ключей доступа. Если константа выключена, система откатывается к старому тяжелому шаблону #ПоЗначениям.
Важной особенностью производительного режима является разделение операций Чтения и Записи:
Для того чтобы подключить новый или доработанный объект конфигурации к производительному RLS, разработчики переопределяют процедуру в модуле менеджера этого объекта:
Процедура ПриЗаполненииОграниченияДоступа(Ограничение) Экспорт
Ограничение.Текст =
"РазрешитьБезОграничений
|ГДЕ
| ЗначениеРазрешено(РеквизитОрганизация)";
КонецПроцедуры
Если вы используете современные конфигурации на базе БСП 3.0 и выше (ERP 2.5, УТ 11.5, КА 2.5, БП 3.0), вам больше не нужно вручную включать скрытые константы через обработку «Все функции» (хотя константы ОграничиватьДоступНаУровнеЗаписей и ОграничиватьДоступНаУровнеЗаписейУниверсально по-прежнему существуют в системе).
Выполним переключение по шагам в пользовательском режиме:
У многих администраторов и разработчиков при первом знакомстве с производительным RLS возникает резонное опасение: «Если права рассчитываются предварительно, значит ли это, что после проведения документа другой пользователь увидит его только тогда, когда отработает регламентное задание по пересчету прав? Не придется ли нам ждать по 20 минут?»
Давайте выясним причину возникновения таких опасений и разберем реальный алгоритм работы системы.
В производительном режиме RLS существует три сценария обновления прав:
Когда вы впервые включаете производительный режим в работающей базе данных, запускается масштабное регламентное (фоновое) задание ОбновлениеДоступаНаУровнеЗаписей. Системе необходимо проанализировать миллионы существующих документов, справочников и регистров, сформировать для них ключи доступа и заполнить служебные регистры сведений (такие как КлючиДоступаКОбъектам, КлючиДоступаПользователей). На больших базах этот процесс действительно может занять несколько часов. Выполнять этот переход рекомендуется исключительно в технологическое окно (например, в выходные дни).
Когда пользователь создает, изменяет или проводит документ в обычном режиме, никаких задержек нет. Ключ доступа для нового или измененного объекта рассчитывается моментально в коде транзакции записи самого объекта. Как только документ записан в базу, другие пользователи с соответствующими правами сразу же увидят его в своих журналах и отчетах. Никакого ожидания регламентного задания в данном сценарии не требуется.
Если администратор системы вносит изменения в глобальные настройки безопасности (например, добавляет нового пользователя в группу доступа, меняет список разрешенных организаций в профиле групп доступа или редактирует рабочие группы объектов в «1С:Документообороте»), то запускается механизм отложенного пересчета прав. В этот момент запускается фоновое задание, которое начинает пересчитывать связи между пользователями и уже существующими ключами доступа. В этот короткий промежуток времени новые права действительно могут примениться не мгновенно, а с задержкой в несколько минут (в зависимости от объема базы и производительности сервера). Однако обычные пользователи, которые просто вводят документы, этого процесса даже не заметят. Для принудительного и оперативного обновления прав конкретного пользователя можно использовать обработку для точечного пересчета прав доступа.
Проанализируем все преимущества и недостатки перехода на новый механизм, чтобы принять взвешенное решение для вашей информационной базы.
Преимущества:
Недостатки и особенности:
КлючиДоступа... могут занять до 10–15% от общего объема базы данных.Подводя итог, можно утверждать, что производительный режим RLS — это стандарт де-факто для современных информационных систем на платформе «1С:Предприятие 8.3». Если ваша компания сталкивается с жалобами пользователей на медленную работу интерфейсов под ограниченными правами, переход на производительный режим RLS должен стать вашим первоочередным шагом по оптимизации системы. Для комплексного анализа и настройки структуры ролей, профилей и ограничений доступа подойдёт обработка для анализа и администрирования прав.