行与列访问控制的性能基础分析

Body

原文链接：http://www.ibm.com/developerworks/ibmi/library/i-performance-basics-for-row-column-access-control/index.html

 

IBM DB2 for i 7.2 版本推出了一项新的数据库安全管理功能，即行与列的访问控制（row and column access control），简称RCAC。RCAC提供了在行与列的级别来管理数据访问的能力。通过特定的SQL语句来控制激活该功能，此时对表上所有的数据访问都有所变化，其中，性能是需要考虑的一个方面。本文将探讨RACA在性能上的一些基本表现，并提供一些对在线实时交易应用下的性能影响的例子。

 

功能简介

IBM i 7.2 版本包含了新的DB2 for i 安全管理的功能，即RCAC。RCAC提供了在行与列级别对访问数据的管理功能，使得从数据库层面来管理数据安全变得更加容易。

DB2 for i 客户会因为以下几个原因，产生足够的业务需求动力来了解并部署RCAC:

• RCAC是以数据为中心的技术。
• RCAC是无需付费的功能。
• RCAC可以部署在由SQL或DDS创建的表上。

想理解这些原因背后的更多细节，请参考本文末尾列出的RCAC的红皮书。和大多数数据库技术一样，如果您的具体实施前考虑到了所有的方面（即有了一个完整的实施策略），您将获得巨大的成功。本文涵盖了其他文章所未涉及的RCAC相关的性能方面的话题。

通过SQL来指定RCAC功能的机制是行的权限和列的掩码，二者定义了如何访问数据库文件中的行与列的规则。您可以通过CREATE PERMISSION 和 CREATE MASK这样的SQL语句来定义和激活行的权限和列的掩码。

• CREATE PERMISSION定义了被数据库自动应用的规则来决定某些行是否可见。
• CREATE MASK则定义了被数据库自动应用的规则，这些规则将作用在被选定的列上。CASE表达式指定列的部分数据如何被返回给用户或应用程序。

CREATE PERMISSION和CREATE MASK语句非常强大和灵活。

 

使用RCAC的SQL工作负载

使用这项强大而灵活的技术，您需要小心的运用及良好的SQL调优实践来保证应用程序的性能。RCAC自身的框架能保证其被非常高效的执行，对SQL查询的性能的影响非常小。为了确认这一点，我们用一组OLTP的SQL工作负载来评估RCAC对负载的性能的影响。同时，我们从以下四个场景来考量：

1. 基准线（不使用RCAC）。
2. 添加行的权限：行的权限创建于工作负载中所有的表上。
3. 添加行的权限和列的掩码：行的权限创建于工作负载中所有的表上，列的掩码则创建于所有常用的被选择的列上。
4. 使用SQL视图来模拟行的权限。

行的权限和列的掩码所使用的RCAC的规则文本是一个对内嵌函数VERIFY_GROUP_FOR_USER的简单调用。VERIFY_GROUP_FOR_USER函数是IBM i 7.2版本中新加的功能，可以通过这个简单而迅捷的机制来判断一个用户是否是某个指定用户组的成员。在工作负载测量中使用的权限、掩码和视图如下面的示例1，2，3所示：

 

示例1：行的权限，用于性能影响的评估：

CREATE PERMISSION library.permissionname ON library.tablename FOR ROWS WHERE                                 VERIFY_GROUP_FOR_USER(SESSION_USER, ‘groupname’) = 1 ENFORCED FOR ALL ACCESS

 

示例2：列的掩码，用于性能影响的评估

CREATE MASK library.maskname ON library.tablename FOR COLUMN columnname RETURN CASE                                 WHEN VERIFY_GROUP_FOR_USER(SESSION_USER, ‘groupname’) = 1                                 THEN columnname                                 ELSE ‘XXXXXXXX’ END

 

示例3：SQL视图，用于性能影响的评估：

CREATE VIEW library.viewname as          SELECT *         FROM library.tablename         WHERE VERIFY_GROUP_FOR_USER(SESSION_USER, 'groupname') = 1;

 

工作负载在不同大小的内存池中测量来确定RCAC框架是否增加了工作负载的内存消耗。如下面的图例1所示，使用RCAC对平均响应时间的影响可以忽略不计。比较RCAC权限的使用和对等的视图，我们可以看到平均交易响应时间上没有可以计量的差异。

图例1：不同大小内存池中的平均交易响应时间

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

图例2展示了四种场景下，不同的内存池大小中标准化的吞吐量。标准化的吞吐量是指在恒定标准的CPU处理器利用率下每秒交易笔数。每秒标准化的交易数越高，则意味着交易负载的每笔交易的CPU处理器占用率越低。与对等的视图应用相比，RCAC权限的标准化吞吐量有1%或更少的差距。与未使用任何额外的安全检查的基准线相比，使用RCAC权限和掩码，有少于5%的差异。

图例2：

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

任何性能数据，对于不同的配置和工作负载，结果都可能会有很大的不同。对于用于本次研究的OLTP工作负载，测量数据表明基本的RCAC应用本身对SQL查询所消耗的CPU处理器和内存使用的影响非常小。但是，权限和掩码的创建语句允许在其中创建复杂的检查。如果行的权限规则文本包含了复杂的与/或数据密集型子查询，应用程序的性能则可能会有负面影响。掩码的创建规则也有同样的现象。如果对于表中的每行或访问的每列，都有至少一个活动的权限或掩码规则，权限或掩码的条件都需要被检验，您可以将之视同为每行或列上都可能要运行一个子查询。所以，您在定义行权限与列掩码时需要非常小心。强烈建议在投放生产前做性能的测试与调优。

 

使用RCAC进行原生的记录级访问

RCAC通过SQL语句来控制，但应用于任何对表的访问。无论是通过SQL，还是原生的记录级访问。RCAC只运行在SQL查询引擎（SQE）中，而不是传统查询引擎（CQE）。对于原本运行在CQE中的原生访问，需要特殊的处理使之进入SQE。这有可能对性能有所提升，因为SQE有着更先进的优化和I/O技术，远比CQE更高效。但是，在查询的打开文件阶段，为了使传统的查询可以在SQE中运行，存在一些额外的特殊处理。通常，查询中处理的数据越多，从SQE所获得的增益越多，可以缓和甚至超越在打开文件阶段的那些特殊处理带来的影响。

为了理解RCAC对使用原生访问的OLTP工作负载的性能的影响，我们同样做了对一组使用COBOL语言通过原生接口访问数据库的订单处理系统的工作负载的测量。对于这组工作负载，为了使用SQE处理数据库查询的特殊处理带来额外的4%的处理器利用率。但是，SQE更高效的I/O处理对硬盘的利用率提升了2%-6%，抵消了使用SQE处理传统打开操作带来的开销。

对于在表中使用了行权限和列许可的原生记录级访问的工作负载，从原生到SQE的性能影响还应该考虑权限和掩码带来的额外的性能开销。这组工作负载在对所有表使用VERIFY_GROUP_FOR_USER检查时，处理器的利用率升高了7%，其中4%用于从原生到SQE的特殊处理，其余的3%则与权限处理有关。

RCAC对于OLTP工作负载的性能影响，总体来说相当小。当然，性能影响会随着工作负载和配置的不同而明显变化。因此，应用RCAC时，性能测试总是必要的。

 

结论：

RCAC提供了非常强大的新功能来确保数据安全。但是，使用这种新技术需要一些性能上的考虑。OLTP的基准测试表明RCAC框架本身对部署了使用VERIFY_GROUP_FOR_USER新功能的权限和掩码的SQL工作负载的性能影响极小。RCAC对于原生的行级别访问，由于在打开文件阶段需要额外的CPU处理器的开销，因此对性能有所影响，当然，对于OLTP工作负载来说，这些额外处理的影响被证明相当小，而SQE在I/O上的处理则更快。从原生记录级访问转向SQL的现代化处理过的应用，可以体会到这种更快的处理所带来的性能上的增益。通常来说，在定义权限和掩码时，必须小心谨慎，因为复杂的权限和掩码安全检查可能会因为减缓数据访问，从而对性能带来负面影响。强烈建议在投产前进行性能测试和调优。

 

资源：

• IBM Knowledge Center - Row and column access control (RCAC)
• Redpaper - Row and Column Access Support in IBM DB2 for i
• DB2 for i forum

原文作者：Sandy Ryan, IBM资深软件工程师

翻译作者：钟嘉田