論數(shù)據(jù)庫防火墻的自我修養(yǎng)之二丨高性能和可擴縮

上周，我們開始討論數(shù)據(jù)庫防火墻的“自我修養(yǎng)”。作為一個技術人，對于文字的造詣遠不及對代碼的掌控，筆者不擅長用華麗的辭藻表達數(shù)據(jù)庫防火墻所背負的重任，在大部分人眼中，它只是一個冰冷的盒子，但筆者依然希望依靠有限的語言能力，用技術人的思維把這樣一個盒子的自我進階之路講給你們聽。

實現(xiàn)了高可用性，解決了最基本的能不能串接部署的問題，數(shù)據(jù)庫防火墻的“人生”可以說成功了一小半，下一個人生挑戰(zhàn)隨之而來：高性能和可擴縮性。

在這里，我們還是有必要先介紹一下數(shù)據(jù)庫防火墻和傳統(tǒng)網絡防火墻的根本性差異，關于深度協(xié)議解析和內容分析的復雜性挑戰(zhàn)

傳統(tǒng)網絡防火墻：通常只分析網絡層的包頭和部分協(xié)議特征，不會對通訊包進行深度分析，一般不會對應答包進行分析。

數(shù)據(jù)庫防火墻：需要對數(shù)據(jù)庫通訊協(xié)議的請求包和應答包（雙向包）進行深度分析：

1、對于請求包，需要解析出包中的SQL語句、參數(shù)化語句、參數(shù)值、跟蹤語句游標。

2、對于應答包，需要解析出返回字段信息、結果集、應答信息等。

3、對于SQL語句，需要進行詞法和語法分析（下一篇文章會介紹為什么需要進行語法分析，而不是簡單的關鍵詞匹配）。

4、對于參數(shù)值，和結果集，需要進行格式轉換，并根據(jù)策略進行必要的內容過濾。

很明顯，二者對通訊包的處理工作量存在很大差異。面對這樣的工作強度，我們必須賦予數(shù)據(jù)庫防火墻一顆強大的“心”，對其進行專門的處理邏輯優(yōu)化和性能優(yōu)化，能夠實現(xiàn)低延遲，保證數(shù)據(jù)庫操作的高吞吐量要求。

核心業(yè)務數(shù)據(jù)庫的高吞吐量和擴縮性挑戰(zhàn)

在以銀行、保險、電信為代表的大型企業(yè)，以稅務、海關、航空為代表的行業(yè)，和以快遞業(yè)為代表的新興領域中，相比大規(guī)模的WEB應用服務器集群，數(shù)據(jù)庫服務器基本上采用的是少量高端設備支撐大規(guī)模的核心應用，無論采用的是RAC集群還是分布式數(shù)據(jù)庫集群，核心業(yè)務場景多數(shù)都是采用非常高端的小型機來搭建，動輒上百甚至幾百個CPU，幾百GB的內存，高端磁盤陣列，支撐起強大的數(shù)據(jù)庫事務吞吐量（TPS）。

在這種場景下，對于串聯(lián)接入的數(shù)據(jù)庫防火墻，面臨“小馬拉大車”的局面，高吞吐量和可擴縮性挑戰(zhàn)有多嚴峻？下面兩個實例充分體現(xiàn)：

首先，介紹一個數(shù)據(jù)庫防火墻的實際經典案例：

數(shù)據(jù)庫防火墻經典案例 拓撲圖

在這個經典案例中，業(yè)務系統(tǒng)采用兩套RAC節(jié)點進行負載均衡（雙活）運行，常規(guī)穩(wěn)定運行的情況下，單套RAC節(jié)點的性能指標需求如下：

SQL吞吐量（SQL/秒）

50000（5萬）

通訊包吞吐量（包/秒）

25萬

會話數(shù)

8000

通訊包延遲

<50微秒(us)

當有一路網絡環(huán)境出現(xiàn)故障，原來分散在2套RAC節(jié)點上的的壓力將集中在一個數(shù)據(jù)庫防火墻上，也就是說，異常情況下，單臺數(shù)據(jù)庫防火墻面臨的是支撐2倍的吞吐量和會話量壓力，同時通訊包的延遲仍然需要保持在50微秒以內。

另外一個想拿來說說的案例，是截止到目前，數(shù)據(jù)庫防火墻面臨的最高端性能案例：

數(shù)據(jù)庫防火墻高端案例 拓撲圖

在這個案例中，整體的數(shù)據(jù)庫集群的性能需求是：

整體數(shù)據(jù)庫集群性能指標

SQL吞吐量（SQL/秒）

200000（20萬）

并發(fā)會話數(shù)

100000（10萬）

數(shù)據(jù)庫集群數(shù)量

4個

折合到單個DBFirewall設備，考慮到設備故障情況，需要支撐的性能指標：

單臺DBFirewall性能指標

SQL吞吐量（SQL/秒）

>120000（12萬）

并發(fā)會話數(shù)

>60000（6萬）

最多支撐數(shù)據(jù)庫集群數(shù)量

2個

高性能和可擴縮性解決方案

通過介紹這兩個經典案例和高端案例，相信不用多說，大家已經能夠感受到數(shù)據(jù)庫防火墻必須具備怎樣一顆強大的心：低延遲、高吞吐量、高可擴縮性能力。

我們確立了這一目標，下一步要做的是制定具體的解決方案，核心技術點有四：

1：極小化每個SQL操作的處理過程

眾所周知，SQL語法分析非常耗時，需要專門進行優(yōu)化：基于詞法和語法分析，對業(yè)務系統(tǒng)的SQL語句進行抽象化處理，形成軟解析結果，并對SQL語句進行序列化、標簽化，這樣就只需要對語法特征不一樣的SQL語句進行解析，而應用系統(tǒng)中SQL語法特征不一樣的SQL語句是有限的，這樣，就能夠極大的減少應用系統(tǒng)SQL語句的語法解析量。

2：無鎖化設計，支撐高并發(fā)下的線性性能

隨著系統(tǒng)并發(fā)量的增加，互斥鎖會成為主要的性能瓶頸點；無鎖化的實現(xiàn)方式是必然，必要時可以通過異步處理來提升吞吐量。

3：低延遲網絡處理技術

隨著吞吐量的增加，串聯(lián)的網絡處理開銷會成為主要的延遲；推薦采用基于Intel DPDK的透明網卡通訊包處理技術，跳過操作系統(tǒng)內核協(xié)議棧的處理，實現(xiàn)低延遲。

4：推薦采用經典的多進程機制

在關系型數(shù)據(jù)庫領域中，最經典的設計要數(shù)Oracle數(shù)據(jù)庫的多進程架構，每個數(shù)據(jù)庫的連接會話對應一個獨立的Oracle進程來處理，這樣的機制為數(shù)據(jù)庫帶來了兩個典型優(yōu)勢：

高可擴縮性：隨著硬件性能的提升，可以實現(xiàn)接近線性的處理性能提升。

高安全性：一個會話（進程）的處理異常，不影響其他會話（進程）。

安華金和數(shù)據(jù)庫防火墻，正是基于以上四點核心技術設計開發(fā)的一款成熟的數(shù)據(jù)庫防火墻產品，且已經經過了社保，金融，運營商等高端行業(yè)的驗證。

至此數(shù)據(jù)庫防火墻的自我修養(yǎng)之二——高性能和可擴縮性介紹完畢，歡迎廣大用戶繼續(xù)關注數(shù)據(jù)庫防火墻的自我修養(yǎng)系列文章。

名詞術語解釋

[1]DPDK：全稱Data Plane Development Kit，是intel開發(fā)的x86芯片上用于高性能網絡處理的基礎庫；是一款數(shù)據(jù)包轉發(fā)處理套件；適合網絡數(shù)據(jù)包分析，處理等操作；對于大數(shù)據(jù)包的轉發(fā)，多核操作有一定的性能提升。

生成海報

免責聲明：本網站內容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網站出現(xiàn)的信息，均僅供參考。本網站將盡力確保所提供信息的準確性及可靠性，但不保證有關資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責。本網站對有關資料所引致的錯誤、不確或遺漏，概不負任何法律責任。任何單位或個人認為本網站中的網頁或鏈接內容可能涉嫌侵犯其知識產權或存在不實內容時，應及時向本網站提出書面權利通知或不實情況說明，并提供身份證明、權屬證明及詳細侵權或不實情況證明。本網站在收到上述法律文件后，將會依法盡快聯(lián)系相關文章源頭核實，溝通刪除相關內容或斷開相關鏈接。