RLS в 1С: универсальный против классического - что выбрать и когда менять
Иван Недомолков · Опубликовано: · Обновлено:
Ограничение доступа на уровне записей (RLS) - механизм, который показывает кассиру его магазин и прячет чужой. В типовых конфигурациях на “Библиотеке стандартных подсистем” таких механизмов два, и выбор между ними - это выбор, чем вы готовы платить: местом на диске и дисциплиной обслуживания или процессорным временем на каждом чтении. Ошибка в выборе стоит дорого - мы видели базу, где она стоила 3,85 терабайта.
Как работает классический RLS
Классический механизм - это условие, которое платформа подставляет прямо в текст запроса каждого списка и отчёта. Кассир открывает список чеков - к запросу добавляется ГДЕ Магазин = &МойМагазин (упрощённо; в реальности - шаблоны ограничений в ролях).
Плюсы: ничего не хранится дополнительно; права меняются мгновенно - поменяли роль, и следующее чтение уже с новым условием; поведение прозрачно и предсказуемо.
Минусы: каждое чтение платит за вычисление условия. На простых отборах это копейки. На сложных ограничениях (иерархии подразделений, пересечения групп доступа) условие превращается в развесистое соединение, и списки начинают ощутимо тормозить - особенно там, где чтений много: кассы, рабочие места менеджеров. Это и есть типовая жалоба “RLS тормозит”: механизм работает правильно, а список открывается секундами. Соседняя жалоба - “из-за RLS отчёт пустой” - на ограничение записей обычно вообще не про него: чаще виновато право просмотра на одно поле, и снимается эта версия одним подсчётом строк. Лечится она разбором конкретных планов запросов, а не отключением ограничений, и входит в оптимизацию производительности 1С.
Как работает универсальный RLS
Универсальный механизм решает проблему “платим на каждом чтении” кардинально: посчитать всё заранее. Система материализует “ключи доступа” - для каждого пользователя и каждого объекта заранее вычисленный ответ “видит / не видит”. В момент чтения остаётся дёшево соединиться с готовой таблицей ключей.
Плюсы: быстрые чтения даже при очень сложной модели прав; нагрузка смещается из горячего пути (открытие списка) в фоновую (пересчёт ключей).
Минусы: это гигантский материализованный кэш со всеми его обязанностями:
- Кэш надо хранить. Таблицы ключей доступа при большом числе пользователей и объектов занимают десятки и сотни гигабайт.
- Кэш надо инвалидировать. Каждое изменение ролей, профилей, состава пользователей ставит в очередь задания пересчёта. Эти очереди перемалывают регламентные задания.
- Кэш живёт своей жизнью. Изменения шаблонов ограничений версионируются - и история версий тоже растёт.
Что происходит, когда обслуживание выключают
Самая опасная особенность универсального механизма: если выключить регламентные задания пересчёта, он не останавливается. Он продолжает прилежно ставить задания в очередь, которые никто не забирает, и копить версии шаблонов, которые никто не читает. Без ошибок и предупреждений.
Реальный случай из нашего проекта обрезки базы 4,2 ТБ: задания пересчёта выключили в 2020 году, потому что они грузили сервер. Шесть лет спустя картина выглядела так:
| Что | Объём |
|---|---|
| История версий шаблонов ограничения доступа | 3,34 ТБ |
| Очереди “пересчитать ключи доступа” (2,37 млрд строк) | ~0,5 ТБ |
| Итого мёртвого кэша | 3,85 ТБ из 4,2 ТБ базы |
Больше 90 % базы - не данные бизнеса, а ТОДО-лист механизма, который никто не собирался выполнять. При этом сам RLS был жив: 208 ролей ежедневно пользовались ограничениями. Мёртвой была только кэширующая часть.
Критерии выбора: когда какой
Классический RLS подходит, если:
- модель прав простая: отбор по магазину/подразделению/организации без глубоких пересечений;
- пользователей и объектов много, а дисциплины обслуживания мало - классика не требует ухода;
- изменения прав должны применяться мгновенно.
Универсальный RLS оправдан, если:
- модель прав действительно сложная и на классике списки уже тормозят;
- есть кому следить за регламентными заданиями пересчёта - постоянно, а не “настроили и забыли”;
- размер таблиц ключей мониторится так же, как размер базы.
Главное правило: универсальный механизм - это не “поставил и забыл”, это подписка на обслуживание кэша. Не готовы платить подписку - берите классику.
Как переехать с универсального на классический
Переход - прикладная задача, но с одной зоной смертельного риска: правами. “Почти как раньше” в правах равно “авария”: кассир, увидевший чужой магазин, - инцидент безопасности; менеджер, потерявший свой, - остановка работы.
Наш процесс на живом проекте (~200 касс, отбор внедрён в 23 документах):
- Инвентаризация: какие роли реально используют ограничения (у нас - 208), какие списки ходят через универсальный механизм.
- Внедрение классических отборов в динамические списки - средствами конфигурации.
- Матрица эквивалентности прав: таблица “роль × сценарий × видимость” до и после - у нас 329 проверок, расхождений 0. Это скучно и обязательно: скучная таблица сильно приятнее интересного инцидента. Как её собрать и снимать срезы автоматически - в отдельной статье: матрица эквивалентности прав.
- Переключение и наблюдение. Только после недель наблюдения кэш универсального механизма можно считать по-настоящему мёртвым.
Эффект на нашем проекте: чтения по списку чеков с учётом RLS - 162 млн → 94. Не в процентах - в 1,7 миллиона раз.
Итог
RLS - это всегда компромисс. Классика: дёшево хранить, дороже читать, ноль обслуживания. Универсальный: дёшево читать, дорого хранить, обязательное обслуживание. Хуже любого из вариантов только один сценарий - универсальный механизм с выключенным обслуживанием: платите и местом, и деньгами, а быстрых чтений всё равно не получаете.
Если подозреваете, что ваш RLS-кэш разросся - проверить это можно за час: постройте карту объёмов базы (метод ПолучитьСтруктуруХраненияБазыДанных() + размеры таблиц) и посмотрите, что в топе. Подробная методика - в расследовании “Мы удалили 97,5 % боевой базы”.
