Механизм Record Level Security (RLS) долгое время считался «узким горлышком» производительности в крупных базах 1С. С выходом новых версий БСП (Библиотеки стандартных подсистем) и актуальных редакций конфигураций (БП 3.0, ЗУП 3.1, ERP) появился новый режим — «Ограничивать доступ на уровне записей универсально». Разберем подробно, что скрывается за этой «волшебной галочкой», как это работает изнутри и с какими подводными камнями можно столкнуться при переходе.
Для начала проанализируем ситуацию, которая существовала в платформе годами. В традиционном RLS ограничение прав накладывается «на лету». Когда пользователь открывает список документов или формирует отчет, платформа берет текст SQL-запроса и динамически добавляет в него сложные условия ГДЕ..., содержащие многочисленные подзапросы к таблицам прав, групп доступа и профилей. Чем сложнее настроены права (например, по организациям, складам и группам физлиц одновременно), тем тяжелее становится итоговый SQL-запрос.
Рассмотрим, как работает универсальный RLS (его также называют RLS на ключах доступа). Основная идея здесь заключается в отказе от динамического формирования тяжелых запросов в пользу предварительного расчета прав. Процесс можно разделить на несколько этапов:
Таким образом, основная вычислительная нагрузка переносится с момента чтения данных на момент их записи или изменения настроек прав.
В типовых конфигурациях, построенных на последних версиях БСП (например, 1С:Бухгалтерия предприятия 3.0), настройка находится в разделе администрирования. Путь обычно выглядит так: Администрирование — Настройки пользователей и прав — Ограничивать доступ на уровне записей. После включения основной настройки может появиться дополнительная опция: «Ограничивать доступ на уровне записей универсально».
Важно понимать, что в некоторых решениях, таких как ЗУП 3.1, этот режим со временем становится основным рекомендованным, так как штатное расписание и сложная структура подразделений в кадровом учете создают запредельную нагрузку на старый механизм RLS.
Выясним основные причины, по которым универсальный механизм выигрывает в производительности:
SELECT.Несмотря на явные плюсы, переход на новый RLS не является «бесплатным». Рассмотрим подробнее недостатки:
1. Нагрузка на запись данных.
Поскольку права теперь «предсчитанные», при записи любого документа система должна проверить, не изменились ли данные, влияющие на ключ доступа. Если в базе происходит массовое перепроведение документов или загрузка данных через DataExchange, нагрузка на сервер вырастет из-за необходимости постоянно обновлять регистры ключей. Рассмотрим пример кода, который вызывается в недрах БСП для обновления этих данных:
// Пример логики обновления ключей (упрощенно)
Процедура ОбновитьКлючиДоступаОбъекта(Ссылка) Экспорт
ПараметрыОбновления = УправлениеДоступомСлужебный.ПараметрыОбновленияКлючейДоступа();
УправлениеДоступомСлужебный.ОбновитьКлючиДоступа(Ссылка, ПараметрыОбновления);
КонецПроцедуры
2. Зависимость от фоновых заданий.
В новом механизме обновление прав часто происходит асинхронно. За это отвечают регламентные задания, такие как ЗаполнениеДанныхДляОграниченияДоступа. Если очередь заданий переполнена или регламентные процессы зависли, может возникнуть ситуация, когда пользователь не видит только что созданный документ, потому что «ключ доступа» для него еще не успел рассчитаться.
3. Взрывной рост объема базы данных. Служебные таблицы ключей доступа могут занимать значительное место. На крупных внедрениях с миллионами документов размер этих таблиц может достигать 10–20% от общего объема информационной базы. К этому нужно быть готовым при планировании дисковых мощностей.
Разберем по шагам, что происходит при включении галочки «универсально» в работающей базе:
Важный совет: Никогда не включайте эту опцию сразу в рабочей базе. Проанализируем ситуацию на копии: запустите переход, замерьте время выполнения регламентных заданий и проверьте, нет ли конфликтов в ваших нетиповых (доработанных) объектах. Если вы добавили свой документ в конфигурацию, убедитесь, что он правильно описан в модуле УправлениеДоступомПереопределяемый, иначе новый RLS может просто игнорировать его или закрыть к нему доступ полностью.
В программе 1С:Зарплата и Управление Персоналом универсальный RLS часто является единственным спасением. Из-за специфики учета (права на физических лиц, сотрудников, зарплатные отчеты) старый RLS делал работу пользователей невыносимо медленной. Новый механизм позволяет разграничить доступ даже в очень крупных холдингах с минимальными задержками при формировании отчетов.
В 1С:Бухгалтерии 3.0 ситуация иная. Если у вас всего 2–3 организации и небольшое количество пользователей, вы можете даже не заметить разницы. Переход имеет смысл только тогда, когда количество юридических лиц в одной базе исчисляется десятками, а пользователи жалуются на долгий отклик при открытии списков «Поступления» или «Реализации».
Проанализировав все «за» и «против», можно сделать вывод: новый универсальный RLS — это мощный инструмент оптимизации для высоконагруженных систем. Он перераспределяет ресурсы сервера, делая работу пользователей в интерфейсе более комфортной за счет небольшого замедления операций записи.
Рекомендуется к переходу, если:
Не рекомендуется, если: