数据库防火墙商业化的前提条件

一、概述

数据库防火墙和一般的传统数据库安全设备不同，它部署在应用服务器和数据库服务器之间。业务系统巨大的流量将穿越数据库防火墙，数据库防火墙任何的风吹草动都会影响业务系统的正常运行。数据库防火墙投放市场之前，不管数据库防火墙功能的多寡，都必须解决两个基本问题：性能和可靠性。

[[234478]]

二、性能

性能主要考虑两方面的影响：延迟和并发。

1. 延迟

延迟：业务操作从指令发出到结果返回之间消耗的时间。

一般来说，绝大部分客户的OLTP(线上交易处理)业务要求秒级响应，这个秒级响应包含了所有的业务处理，包括：客户端的处理(比如浏览器)延迟，业务网络延迟，应用服务器处理延迟，数据库网络延迟，数据库处理延迟等。对于数据库防火墙来说，应用服务器处理延迟和数据库处理延迟之间增加了一个数据库防火墙处理延迟。

我们来看看一般OLTP系统的常规情况，数据库网络延迟一般1ms之内，数据库处理延迟大部分在0.1ms-10ms之间，少部分会在10ms-100ms之间，极少出现几百ms以上的延迟。

为了简化说明，我们把数据库网络延迟标定为1ms，每次数据库响应处理延迟时间标定为2ms，每笔业务平均由20条SQL语句构成，则每次延迟时间为3ms，每笔业务的响应时间为60ms，每秒钟可以处理16.8笔业务。如果数据库防火墙的处理延迟时间为1ms，则每次处理延迟增加为4ms，总处理时间增加为80ms，每秒钟可以处理12.5笔业务。

下面我们从三种不同的业务场景来分析：独占数据库连接(无数据库连接池)、数据库连接池和短连接业务。大部分C/S应用都独占数据库连接，大部分B/S应用都采用数据库连接池，短连接的应用非常少见，只出现在极少数据库处理的应用中。

(1) 独占数据库连接

独占数据库连接应用中，数据库防火墙的接入在每次处理中增加1ms，整体响应中增加了20ms，也就是从1000ms增加到了1020ms，这个延迟增量一般情况下不会对于业务体验造成任何影响。

(2) 数据库连接池

不同于独占数据库连接，数据库连接池为不同业务操作的共享单元。假设数据库连接池数量为200个，冗余20%，可用数量为160个。显然，引进数据库防火墙之后，业务处理能力从16.8 * 160 = 2688/s下降为12.5*160=2000/s，吞吐量下降25.6%。当你需要比较2000笔/s更高吞吐量的时候，数据库防火墙的接入將带来业务线的影响。在这种情况下，你需要把数据库连接池数量至少增加26%，也就是252个，这个时候数据库连接池的处理能力將恢复到2688笔/s，整体业务感知的影响也仅仅从1000ms增加到了1020ms，基本可以被忽略。

(3) 短连接业务

在短连接业务中，数据库连接消耗的时间將纳入业务响应时间。以Oracle数据库为例子，一个数据库连接的建立消耗时间在120ms-200ms，数据库防火墙增加的每次1ms延迟和合计20ms延迟基本不会产生业务层面的影响。

(4) 数据库响应处理的影响

在上面的讨论中都假设了数据库不会受到影响，但是事实上数据库防火墙的加入会到数据库处理产生影响，其影响等同于网络速度下降。一般而言，延迟造成的影响主要在于增加了数据被锁定的时间，从而会从根本上影响数据库并发性。

我们以简单的update为例子：

update customer set balance=500 where cust_id=10080;  
commit; 

可以看到cust_id=10080这一行的锁定周期从3ms增加到了4ms，锁定周期增加了33.3%，这个增加的锁定时间会在一定时间影响数据库的并发性。

2. 并发性

对于一个企业级数据库，几千甚至几万个数据库连接是很常见的，数据库防火墙需要在处理高并发量的同时保持延迟时间的稳定。在现实场景中，随着业务并发程度的上升，响应时间下跌甚至于非线性下跌都是很常见的事情。我们在这里不讨论如何实现高并发，只是说明并发性会严重影响响应延迟。

3. 性能延迟的可接受性

从上面计算可以看到，绝大部分的业务应用在数据库防火墙增加1ms延迟时间不会对业务造成太大影响。对于高度并发性或者响应时间极为苛刻的业务应用，1ms延迟具有比较大的风险，需要更低延迟的数据库防火墙支持，300us-500us的延迟是一个相对合理的数值。当然如果你的网络环境甚至已经在多接入一个网络交换机(延迟时间一般在100-300us)都会对业务造成明显影响的时候，显然增加数据库防火墙接入是不合适的。

三、可靠性

性能是一个复杂的问题，可靠性对于数据库防火墙来说就是一个极为简单的命题。由于数据库防火墙部署在应用服务器和数据库服务器之间，数据库防火墙的任何故障显然会导致业务操作失败，在数据库防火墙无法工作的时候导致所有业务中断。

相信任何用户在安全和业务保障之间都会优先选择业务保障而暂时放弃安全。基于这个考虑，一个很朴素的需求就是：在数据库防火墙出现任何故障，包括软件故障，硬件故障等，依然需要保障业务运行不要被中断和影响。

1. bypass

当防火墙软件或者硬件故障的时候，可以自适应降级成网络通路设备，保证业务运行不会受到防火墙软件或者硬件故障的影响。

2. 可靠性保持

数据库网络往往具有很高的冗余措施，数据库防火墙的接入要求不会改变原有网络的冗余结构，保持原有网络的可靠性。

四、总结

数据库防火墙商业化需要两个基本前提：可以接受的性能和可靠性保障，在这两个基本前提解决之前，任何数据库防火墙产品都只能是实验室产品而无法投放市场。

从性能的角度看，绝大部分情况下1ms以下的延迟都可以接受，对于高并发的复杂业务或者响应苛刻业务会需要更高的延迟性能，要求在500us以下。