使用查找表使用行级安全性的性能问题

Question

我已经在SQL Server 2016上实现了行级安全性。我认为我的安装复杂，但我们的安全要求很复杂。

这是在数据仓库的上下文中。我有基本的事实和维度表。我通过以下设置将行级安全性应用于我的维度表之一：

  

表1 ：dimDataSources（标准物理表）
  表2 ：dimDataSources_Secured（“内存优化”表）

我在dimDataSources_Secured（内存中）上创建了一个使用本机编译功能的安全策略。该函数读取另一个内存优化表，该表包含查找值和可以读取记录的Active Directory组。 该函数使用is_member()函数为我的组所允许的所有记录返回1。

因此上下文似乎有点复杂，但到目前为止它仍然有效。 但是...现在我可以在事实表的连接中使用它，并且我们的性能受到了影响。在这里，我不是在事实表上直接应用行级安全性，而只是在维度表上。

所以我的问题是如果我运行此命令：

SELECT SUM(Sales) FROM factSales

它迅速返回，比方说2秒。

如果我运行相同的查询但在安全表（或视图）上具有联接，则将花费5-6倍的时间：

SELECT SUM(Sales) FROM factSales f
INNER JOIN dimDataSources_Secured d ON f.DataSourceKey = d.DataSourceKey

这仅根据我的广告组检索我有权访问的源。 当执行计划更改时，似乎它会快速检索事实表数据，但随后将在内存表中进行嵌套循环查找以获取允许的记录。

该行为是由使用过滤谓词功能引起的吗？ 是否有人在使用行级安全性方面有好或坏的经验？ 是否足够成熟以投入生产？ 是否适合用于数据仓库（即处理大量数据）？

不写小说就很难在我的实际功能和查询上提供更多细节。我主要是在寻找准则或替代方法。

Answer 1

  

是由使用谓词谓词引起的行为   功能？任何人使用行级都有好或坏的经验   安全？是否足够成熟以投入生产？好不好   数据仓库（处理大量数据）的候选人？

是的，使用RLS会对性能产生影响。亚伦·伯特兰德（Aaron Bertrand）于2017年3月在上面写下了不错的piece。 Ben Snaidero在2016年写的很好。微软还提供了guidance的模式以限制对性能的影响。

我从未见过为OLAP模式实现RLS，因此我无法对此发表评论。没有看到过滤器谓词，很难说，但这通常就是魔鬼所在的地方。