При масштабировании розничной сети до 100 и более торговых точек перед разработчиками и архитекторами встает острый вопрос разграничения прав доступа. Типовой механизм RLS (Record Level Security) кажется логичным решением, однако на практике он может стать «бутылочным горлышком» всей системы. Рассмотрим подробнее, как ведет себя RLS в высоконагруженных базах 1С:Розница 2.2, проанализируем реальный опыт внедрений и определим оптимальные стратегии работы с большими объемами данных.
Прежде чем переходить к конкретным цифрам, проанализируем механику работы RLS. Этот механизм работает на уровне СУБД, автоматически добавляя дополнительные условия к каждому SQL-запросу. Разберем основные причины деградации производительности:
JOIN) с таблицами прав доступа.tempdb.Проанализируем ситуацию, когда в базе работают 700+ магазинов. Практика показывает, что использование классического RLS в таких масштабах практически невозможно. Пользователи сталкиваются с тем, что простейшие действия, такие как открытие списка документов или проведение чека, могут выполняться по несколько минут или даже «повесить» сеанс на полчаса.
В базах объемом более 600 Гб включение RLS часто приводит к полной остановке операционной деятельности. Даже если данных пока немного, при достижении порога в 1000–3000 документов в день производительность начнет падать в геометрической прогрессии. Проблема усугубляется, если пользователю назначено более одной роли с ограничениями — платформа вынуждена объединять условия (OR/UNION), что еще сильнее утяжеляет запросы.
Для 100 магазинов наиболее стабильным вариантом остается создание РИБ по магазинам. Выясним причины, почему этот метод предпочтительнее работы всех касс напрямую в Центральной Базе (ЦБ):
RLS в периферийной базе, так как «чужих» данных там просто физически нет.Однако РИБ накладывает обязательства по контролю обменов. Если ваша цель — видеть актуальные остатки в режиме реального времени во всей сети, перейдем к рассмотрению других вариантов.
Если работа в единой базе критична, рассмотрим вариант программного ограничения доступа. Вместо включения флажка «Ограничивать доступ на уровне записей» в настройках программы, разработчики реализуют логику фильтрации самостоятельно. Рассмотрим, как это сделать:
ПараметрыСеанса.ТекущийМагазин записывается ссылка на его торговую точку.ГДЕ Магазин = &ТекущийМагазин.Такой подход работает молниеносно, так как SQL-запрос остается простым и понятным для оптимизатора. Единственный минус — риск прямого доступа к данным через консоль запросов, но для линейного персонала (директора магазинов, кассиры) эта защита является достаточной.
Начиная с версии платформы 8.3.18, компания 1С внедрила упрощенный (производительный) режим RLS. Проанализируем ситуацию: если ваша конфигурация поддерживает этот режим, тормоза будут значительно меньше. Платформа заранее рассчитывает права доступа и сохраняет их во временных таблицах СУБД. Если вы все же решили использовать штатный механизм, обязательно убедитесь, что:
Если работа с RLS в ЦБ на 200 пользователей неизбежна, требования к «железу» возрастают в разы. Выясним, на что обратить внимание при подборе сервера:
RLS плохо распараллеливается, поэтому нужны CPU с частотой от 4.0 ГГц. Процессоры с большим количеством ядер, но низкой частотой (например, 2.2 ГГц), покажут крайне плохие результаты.tempdb, где СУБД будет строить таблицы ограничений.Подводя итог, можно сказать: классический RLS в типовой Рознице 2.2 на 100 магазинов — это высокий риск остановки работы из-за тормозов. Если вы находитесь на этапе проектирования, выберите один из следующих путей:
RLS в пользу программных фильтров в формах и отчетах. Это потребует доработки конфигурации, но обеспечит мгновенный отклик системы.Помните, что тестирование на пустой базе не покажет реальной картины. Нагрузочное тестирование следует проводить на копии, содержащей объем данных, эквивалентный хотя бы году работы вашей сети.