資料庫防火牆商業化的前提條件

資料庫防火牆和一般的傳統資料庫安全裝置不同，它部署在應用伺服器和資料庫伺服器之間。業務系統巨大的流量將穿越資料庫防火牆，資料庫防火牆任何的風吹草動都會影響業務系統的正常執行。資料庫防火牆投放市場之前，不管資料庫防火牆功能的多寡，都必須解決兩個基本問題：效能和可靠性。

 效能主要考慮兩方面的影響：延遲和併發。

延遲：業務操作從指令發出到結果返回之間消耗的時間。

一般來說，絕大部分客戶的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應用都採用資料庫連線池，短連線的應用非常少見，只出現在極少資料庫處理的應用中。 

獨佔資料庫連線應用中，資料庫防火牆的接入在每次處理中增加1ms，整體響應中增加了20ms，也就是從1000ms增加到了1020ms，這個延遲增量一般情況下不會對於業務體驗造成任何影響。 

不同於獨佔資料庫連線，資料庫連線池為不同業務操作的共享單元。假設資料庫連線池數量為200個，冗餘20%，可用數量為160個。顯然，引進資料庫防火牆之後，業務處理能力從16.8 * 160 = 2688/s下降為12.5*160＝2000/s，吞吐量下降25.6%。當你需要比較2000筆/s更高吞吐量的時候，資料庫防火牆的接入將帶來業務線的影響。在這種情況下，你需要把資料庫連線池數量至少增加26％，也就是252個，這個時候資料庫連線池的處理能力將恢復到2688筆/s，整體業務感知的影響也僅僅從1000ms增加到了1020ms，基本可以被忽略。 

在短連線業務中，資料庫連線消耗的時間將納入業務響應時間。以Oracle資料庫為例子，一個資料庫連線的建立消耗時間在120ms-200ms，資料庫防火牆增加的每次1ms延遲和合計20ms延遲基本不會產生業務層面的影響。 

在上面的討論中都假設了資料庫不會受到影響，但是事實上資料庫防火牆的加入會到資料庫處理產生影響，其影響等同於網路速度下降。一般而言，延遲造成的影響主要在於增加了資料被鎖定的時間，從而會從根本上影響資料庫併發性。

我們以簡單的update為例子：

       update customer set balance=500 where cust_id=10080;

       commit;

可以看到cust_id＝10080這一行的鎖定週期從3ms增加到了4ms，鎖定週期增加了33.3%，這個增加的鎖定時間會在一定時間影響資料庫的併發性。 

對於一個企業級資料庫，幾千甚至幾萬個資料庫連線是很常見的，資料庫防火牆需要在處理高併發量的同時保持延遲時間的穩定。在現實場景中，隨著業務併發程度的上升，響應時間下跌甚至於非線性下跌都是很常見的事情。我們在這裡不討論如何實現高併發，只是說明併發性會嚴重影響響應延遲。 

從上面計算可以看到，絕大部分的業務應用在資料庫防火牆增加1ms延遲時間不會對業務造成太大影響。對於高度併發性或者響應時間極為苛刻的業務應用，1ms延遲具有比較大的風險，需要更低延遲的資料庫防火牆支援，300us-500us的延遲是一個相對合理的數值。當然如果你的網路環境甚至已經在多接入一個網路交換機（延遲時間一般在100-300us）都會對業務造成明顯影響的時候，顯然增加資料庫防火牆接入是不合適的。 

相信任何使用者在安全和業務保障之間都會優先選擇業務保障而暫時放棄安全。基於這個考慮，一個很樸素的需求就是：在資料庫防火牆出現任何故障，包括軟體故障，硬體故障等，依然需要保障業務執行不要被中斷和影響。 

當防火牆軟體或者硬體故障的時候，可以自適應降級成網路通路裝置，保證業務執行不會受到防火牆軟體或者硬體故障的影響。 

資料庫網路往往具有很高的冗餘措施，資料庫防火牆的接入要求不會改變原有網路的冗餘結構，保持原有網路的可靠性。