SQL Server 2016 представил новую функцию под названием Row-Level Security (RLS), которая позволяет осуществлять тонкую настройку контроля доступа к данным строк в таблице. В то время как безопасность данных является важной, также важно поддерживать оптимальную производительность. В этой статье мы рассмотрим накладные расходы на производительность, связанные с внедрением RLS, и обсудим способы улучшения производительности.

Настройка теста

Прежде чем приступить к анализу производительности, давайте настроим тестовую среду. Мы создадим таблицу с образцовыми данными и таблицу пользователей с внешним ключом, связанным с таблицей данных. Таблица с образцовыми данными будет содержать большое количество данных для нашего теста производительности. Кроме того, мы создадим индексы на столбцах, которые обычно индексируются в производственной системе, чтобы обеспечить реалистичные тестовые сценарии.

Базовый тест

Теперь, когда наша тестовая среда готова, давайте запустим некоторые базовые запросы, чтобы установить показатели производительности. Мы будем выполнять запросы с использованием двух разных учетных записей пользователей: одной с привилегиями sysadmin и другой с доступом на чтение ко всем таблицам в тестовой базе данных. Эти запросы будут служить точкой отсчета для сравнения производительности с и без RLS.

Внедрение Row-Level Security

Затем мы внедрим RLS, создав предикатную функцию безопасности и политику безопасности. Предикатная функция безопасности будет фильтровать данные на основе пользователя, запрашивающего таблицу. Политика безопасности будет применять эту функцию к таблице данных. После внедрения мы повторно выполним наши тестовые запросы, чтобы наблюдать влияние RLS на производительность.

Результаты производительности

Из результатов производительности видно, что существует некоторые накладные расходы, связанные с RLS. Для запросов, выполняемых пользователем sysadmin, накладные расходы минимальны и главным образом связаны с дополнительным использованием процессора. Однако для запросов, выполняемых обычным пользователем, накладные расходы более значительны. Это особенно заметно при выполнении SELECT-запроса без предложения WHERE, что приводит к полному сканированию таблицы и увеличению количества чтений.

Улучшение производительности

В то время как RLS предоставляет преимущества в плане безопасности данных, важно учитывать влияние на производительность. Вот несколько стратегий для улучшения производительности при использовании RLS:

• Оптимизация предикатной функции безопасности: Проверьте логику предикатной функции безопасности и убедитесь, что она максимально эффективна. Избегайте ненужных вызовов функций или сложных вычислений.
• Оптимизация индексов: Проанализируйте шаблоны запросов и создайте соответствующие индексы для улучшения производительности запросов. Рассмотрите индексацию столбцов, используемых в предикатной функции безопасности.
• Разделение данных: Если таблица данных большая, рассмотрите возможность разделения ее на основе критериев предикатной функции безопасности. Это может помочь уменьшить количество строк, сканируемых при выполнении запроса.
• Кэширование: Внедрите механизмы кэширования для уменьшения количества вызовов функций и улучшения общей производительности. Это можно достичь с помощью кэширования на уровне приложения или с использованием техник кэширования на уровне базы данных.

Реализуя эти стратегии, вы можете снизить накладные расходы на производительность, связанные с RLS, и обеспечить оптимальную производительность при сохранении безопасности данных.

Заключение

Row-Level Security в SQL Server предоставляет мощный механизм для контроля доступа к данным строк. Однако важно учитывать влияние на производительность при внедрении этой функции. Оптимизируя предикатную функцию безопасности, оптимизируя индексы, рассматривая разделение данных и внедряя механизмы кэширования, вы можете улучшить производительность при сохранении безопасности данных. Важно найти баланс между безопасностью и производительностью, чтобы обеспечить эффективную базу данных.