隨著 IBM? WebSphere? Information Integrator 8.2 的發(fā)布，IBM 提供了一項稱作隊列復(fù)制或 Q 復(fù)制的功能，使數(shù)據(jù)庫復(fù)制有了很大的進(jìn)步。新的復(fù)制架構(gòu)是隨著對高性能（高事務(wù)量，低延時）的需求而出現(xiàn)的。本文將介紹新的 Q 復(fù)制架構(gòu)，預(yù)期它有什么樣的性能，以及哪些因素對性能有影響。此外，我們還將研究實驗室測試時在 AIX? 和 z/OS? 平臺上所使用的例子。 注意：在閱讀本文之前，請先閱讀免責(zé)聲明。 隨著 WebSphere Information Integrator 8.2 的發(fā)布，IBM 提供了一個稱作隊列復(fù)制 或 Q 復(fù)制 的功能，使數(shù)據(jù)庫復(fù)制有了很大的進(jìn)步。這種新的復(fù)制架構(gòu)是隨著對高性能的需求而出現(xiàn)的，高性能是指高事務(wù)量和低延時，這里的延時是從在源數(shù)據(jù)庫上提交對源數(shù)據(jù)庫的更改到這些更改在目標(biāo)數(shù)據(jù)庫上完成提交這中間所經(jīng)歷的時間。 本文描述新的 Q 復(fù)制架構(gòu)，討論預(yù)期的性能水平，以及影響性能的一些因素，并給出在實驗室測試時在 AIX 和 z/OS 平臺上所使用的例子。文中的信息對于那些有興趣使用 Q 復(fù)制，以及想知道 Q 復(fù)制對性能的影響的客戶來說會有所幫助。
數(shù)據(jù)復(fù)制技術(shù)對于 IBM 或 DB2? 來說并不是什么新技術(shù)，早在十年前，該技術(shù)就第一次被引入到一個稱作 DataPropagator? Relational（DPropR）的產(chǎn)品當(dāng)中。從那以后，它的名稱和包有所變化，產(chǎn)品的廣度和功能有所擴(kuò)展，形成的一組產(chǎn)品也獲得了實實在在的商業(yè)上的成功。 現(xiàn)有的復(fù)制架構(gòu)是 SQL 復(fù)制，它依然與 Q 復(fù)制并駕齊驅(qū)，并且在多種客戶場景中很可能仍將是最佳解決方案。 對于 SQL 復(fù)制，數(shù)據(jù)庫的更改可以被捕捉，并臨時地存儲在稱作關(guān)系中間表（staging table）的關(guān)系表中。然后，從目標(biāo)系統(tǒng)上的一個客戶接口可以讀取這些關(guān)系中間表，并將它們應(yīng)用于目標(biāo)表。SQL Replication 與 DB2 for Linux?、DB2 for UNIX? 和 DB2 for Windows? 一起打包。在 z/OS 上，SQL Replication 以 DB2 Data Propagator 的形式提供給用戶，此外，它還包含在所有具有復(fù)制功能的 WebSphere Information Integrator 產(chǎn)品當(dāng)中。對于某些場景，例如那些以非 DB2 數(shù)據(jù)庫作為源或目標(biāo)的場景，SQL Replication 可能仍是目前的最佳選擇。 雖然 SQL Replication 有這些成功之處，但它也面臨一些技術(shù)上的挑戰(zhàn)，特別是當(dāng)客戶系統(tǒng)有所增長，性能需要日益提高的時候，挑戰(zhàn)尤為突出。而 Q Replication 就是為滿足這些性能需求而設(shè)計的，此外，它還增加了一些功能，提高了可管理性。 系統(tǒng)在規(guī)模上不斷增長，打破了吞吐率的限制。與此同時，客戶需要更多地實時訪問被復(fù)制的更改。這些實時更改操作常常需要朝多個方向流動，因此造成對同步兩個或更多系統(tǒng)的需要，以及當(dāng)這些系統(tǒng)并發(fā)地更改相同數(shù)據(jù)時解決沖突問題的需要。 客戶對于數(shù)據(jù)庫復(fù)制有很多方面的需要，數(shù)據(jù)庫復(fù)制這個過程常常需要謹(jǐn)慎地計劃和調(diào)度。下面是數(shù)據(jù)庫復(fù)制的一些傳統(tǒng)用法和未來的趨勢：
從下面的圖 1 可以看到 Q 復(fù)制使用消息隊列在源數(shù)據(jù)庫和目標(biāo)數(shù)據(jù)庫之間傳遞事務(wù)數(shù)據(jù)更改的情況。這里所使用的隊列系統(tǒng)是 IBM 的一個旗艦消息傳遞產(chǎn)品，即 WebSphere MQ。WebSphere MQ 隨用于 Linux、UNIX 和 Windows 平臺的 WebSphere Information Integrator 一起打包，是 z/OS 環(huán)境的必備產(chǎn)品。 圖 1. Q 復(fù)制  Q 復(fù)制有兩大基本組件，Q Capture 和 Q Apply。Q Capture 從數(shù)據(jù)庫恢復(fù)日志讀取數(shù)據(jù)，并用從提交的事務(wù)中選擇的數(shù)據(jù)更改構(gòu)造消息。然后，這些消息被寫入到一個或多個 MQ 隊列。這意味著這個過程對于源數(shù)據(jù)庫來說是異步的，只有在數(shù)據(jù)庫更改已經(jīng)提交到源數(shù)據(jù)庫時，那些消息才會發(fā)送到 MQ。每條邏輯消息代表一個完整的、已提交的數(shù)據(jù)庫事務(wù)。Q Apply 從消息隊列接收事務(wù)消息，并將每條消息作為一個事務(wù)單元應(yīng)用到目標(biāo)系統(tǒng)。 WebSphere MQ 的消息傳遞功能負(fù)責(zé)處理跨異構(gòu)系統(tǒng)和網(wǎng)絡(luò)協(xié)議傳遞消息的問題。在內(nèi)部，MQ 使用日志文件和數(shù)據(jù)文件，以類似于數(shù)據(jù)庫管理系統(tǒng)可能使用的方式，來管理消息的完整性和持久性。這些文件實質(zhì)上替代了 SQL 復(fù)制中由 DB2 處理的關(guān)系中間表和相關(guān)數(shù)據(jù)庫日志記錄功能。 如前所述，Q 復(fù)制允許有多個數(shù)據(jù)副本，該數(shù)據(jù)可能在多個站點發(fā)生改變，并且數(shù)據(jù)庫更改可以朝多個方向流動。這也意味著可能出現(xiàn)沖突，例如，當(dāng)多個站點更新相同的數(shù)據(jù)行時就會發(fā)生沖突。Q 復(fù)制為解決那些沖突提供了一種機(jī)制。 Q 訂閱定義源表與目標(biāo)表之間的關(guān)系，而且可以用單向、雙向或點對點這三種映射類型來定義。兩個服務(wù)器之間任意方向的復(fù)制的數(shù)據(jù)更改可以定義為雙向和點對點。雙向映射計算源數(shù)據(jù)庫和目標(biāo)數(shù)據(jù)庫上的數(shù)據(jù)值，從而提供了一種簡單的、低成本的沖突檢測和沖突解決方法。 點對點映射依靠添加到源應(yīng)用程序數(shù)據(jù)上的版本信息，提供了更健壯的沖突檢測和沖突解決。版本信息是在 Q 復(fù)制內(nèi)部在底層數(shù)據(jù)庫引擎中通過觸發(fā)器實現(xiàn)的。雖然從性能的角度來看，這種方法成本更高，但它允許兩個或更多可以并行地更新的數(shù)據(jù)庫的聚合（convergence）。本文的第 5 節(jié)比較了這幾種方法的性能。
Q 復(fù)制與 SQL replication 相比的性能 下面的 圖 2 和 3 說明了在 AIX 和 z/OS 環(huán)境下 Q 復(fù)制與 SQL 相比的優(yōu)勢。這兩組使用同等工作負(fù)載和配置的測試都表明：Q 復(fù)制的吞吐率幾乎是 SQL 復(fù)制的三倍，而且在吞吐率的峰值處仍然維持著低得多的延遲。在這兩種配置中，Q 復(fù)制每秒可以復(fù)制 12,000 多行，而端到端的延遲低于 2 秒，在吞吐率較低的情況下，這種延遲常常低于 1 秒。在這兩次測試中使用的工作負(fù)載只包含 INSERT，以模擬適度復(fù)雜的事務(wù)，每個事務(wù)有 10 個 INSERT 操作，行大小為 212 字節(jié)。這種非常簡單的工作負(fù)載有它的用處，因為它關(guān)注復(fù)制過程執(zhí)行的任務(wù)，而減少了測試中使用的硬件資源。例如，我們不需要像真正的應(yīng)用程序那樣為 SELECT 或應(yīng)用程序處理分配硬件資源。關(guān)于本文中使用的工作負(fù)載和配置的更多信息，請參閱“工作負(fù)載和配置”一節(jié)。 還應(yīng)注意，與 SQL 復(fù)制相比，Q 復(fù)制真正降低的延遲甚至要好于上面圖中顯示的那樣。Q 復(fù)制提供了非常好的性能監(jiān)控功能，包括對端對端延遲的真實度量，這個延遲是指從源上提交事務(wù)開始到事務(wù)在目標(biāo)上完成提交這之間的時間。對于 SQL 復(fù)制，這些監(jiān)控功能不存在，因此基準(zhǔn)應(yīng)用程序采用一種技術(shù)來度量平均行延遲。由于每個事務(wù)涉及多個行，SQL 復(fù)制的事務(wù)延遲實際上要高于圖中顯示的延遲。 對于 z/OS 和 AIX 這兩個測試，Q 復(fù)制測試表明復(fù)制吞吐率限制大約是每秒 12,000 行，當(dāng)吞吐率達(dá)到這個高度時，各種資源變得飽和，從而導(dǎo)致延遲增加。最為顯著的是，在達(dá)到飽和點之前，延遲一直很穩(wěn)定，我們的經(jīng)驗是，大多數(shù)客戶的需求都低于這些限制。但為了保險起見，建議從每秒復(fù)制的行數(shù)這一角度估計客戶的吞吐率需求，并確保在峰值情況下仍然低于限制。此外，這些限制并不是絕對的，要受工作負(fù)載和配置變化的影響，這在后面會討論到。 在圖 2 中可以看到，Q 復(fù)制在 z/OS 中有更高的吞吐率和更低的延遲.... 圖 2. Q 復(fù)制與 SQL replication 的性能比較 - z/OS ...在 AIX 上也同樣如此。 圖 3. Q 復(fù)制與 SQL replication 的性能比較 - AIX 有很多因素可以幫助提高 Q 復(fù)制的性能，其中包括： 減少 DB2 日志記錄活動 對于 SQL 復(fù)制，數(shù)據(jù)庫更改是在源數(shù)據(jù)庫上的 DB2 關(guān)系中間表中捕捉的。這要求將附加的日志記錄寫入到 DB2 日志中。（如果捕捉所有數(shù)據(jù)庫更改，那么就會導(dǎo)致在中間關(guān)系表中寫入附加的用于插入和刪除的日志，從而潛在地使 DB2 日志的寫活動增加到原來的三倍。而對于 Q 復(fù)制，關(guān)系中間表是用 MQ 隊列捕捉的。數(shù)據(jù)文件和日志文件提供 MQ 隊列的底層存儲，只要這些文件放在與 DB2 日志不同的磁盤上，就可以減少日志文件的內(nèi)容。 減少對處理器的使用 由于多種原因，Q 復(fù)制在源服務(wù)器上比 SQL 復(fù)制要消耗更少的處理器周期，而在目標(biāo)服務(wù)器上消耗得要更多些，但總體上仍然是少一些。這是至關(guān)重要的，因為源服務(wù)器最可能運行“生產(chǎn)”應(yīng)用程序，在那上面的處理器周期是比較珍貴的。 下面的圖 4 展示了在 z/OS 上 SQL 復(fù)制和 Q 復(fù)制對處理器的使用情況的比較。這個圖給出了源系統(tǒng)和目標(biāo)系統(tǒng)上處理器成本的兩個度量：每個被復(fù)制的行占用的微秒數(shù)，以及每一千個被復(fù)制的行每秒所需的 MIPS(1) (2)。您可以使用這兩個度量來理解不同復(fù)制方法在處理器成本方面的不同之處，以及復(fù)制的粗略的“能力規(guī)劃（capacity planning）”估計。 這些測試試圖用大致相等但不相同的吞吐量來比較這兩個度量點。在所有情況下，復(fù)制都可以滿足工作負(fù)載的需求，并且延遲要小于 5 秒。 圖 4 說明了 Q 復(fù)制所減少的 CPU 消耗：
圖 4. Q 復(fù)制- 減少的處理器消耗 下面是從這些測試中觀察到的一些方面：
增加 Q Apply 處理中的并行度 Q Apply 采用高度的并行性，這是支撐復(fù)制目標(biāo)上源應(yīng)用程序的吞吐率需求的關(guān)鍵。如果一個源應(yīng)用程序采用高度的并行性來取得高吞吐率，那么 Q Apply 組件可以使用并行來跟上步伐。 如下面的圖 5 所示，對于每個傳入的接收隊列，Q Apply 啟動一個瀏覽器（可以將這個過程看作是“瀏覽隊列”）。Q Apply 從該隊列讀取事務(wù)，檢查事務(wù)之間的依賴關(guān)系，并基于這種依賴分析通過并行的 Q Apply 代理應(yīng)用數(shù)據(jù)更改。一個Q Apply 程序可以處理多個消息隊列（每個隊列一個瀏覽器），每個瀏覽器可以啟動多個代理。Q Apply 代理可以并行地應(yīng)用事務(wù)，以跟上發(fā)起事務(wù)的源應(yīng)用程序的并行度，從而大大增加復(fù)制吞吐率。 圖 5. Q Apply 過程 理論上，SQL 復(fù)制可以通過啟動 SQL Apply 程序的多個實例取得一定程度的并行性，但這需要管理員將表劃分到適當(dāng)?shù)慕M中，并平衡這些組之間的工作負(fù)載。此外，它不能像 Q 復(fù)制那樣允許在一個很活躍的表內(nèi)使用并行。 記住，即使只用一個消息隊列和一個瀏覽器，Q 也可以使用多個代理（默認(rèn)情況下每個瀏覽器 16 個代理），而不需要管理員做額外的工作。Q Apply 可以自動判斷事務(wù)之間的依賴關(guān)系，因此可以按適當(dāng)?shù)捻樞驊?yīng)用數(shù)據(jù)更改。管理員可以定義附加的隊列，但這需要格外小心，因為沒有事務(wù)可以跨消息隊列修改表。而對于完全獨立的應(yīng)用程序來說，這樣做也許是合適的。 下面的圖 6 說明了增加 Q Apply 代理和瀏覽器數(shù)量的影響。在這個測試中，我們使用“預(yù)先裝載”的消息隊列測試 Q Apply，以排除 Q Capture 方面的任何約束。此外，在 z/OS LPAR(3) 上使用了 6 個處理器。您可以看到，增加代理的數(shù)量可以大大提高吞吐率，增加瀏覽器也可以得到一定的好處。使用一個消息隊列和默認(rèn)的 16 個代理對于大多數(shù)應(yīng)用程序來說通常已經(jīng)足夠了，在這里，最大工作負(fù)載是每秒 15,000 個事務(wù)（這確實是一個相當(dāng)大的工作負(fù)載）。 圖 6. Q Apply 在 z/OS 中的吞吐率
下面的圖 7 比較了不同復(fù)制方案的吞吐率：沒有復(fù)制的 INSERT 工作負(fù)載、單向映射、雙向映射和點對點映射。在這些測試中使用的工作負(fù)載由 8 個并發(fā)的執(zhí)行 INSERT 操作的任務(wù)組成，事務(wù)之間有短暫的應(yīng)用程序延遲(4)。然而，在雙向映射和點對點映射的測試中，相同的工作負(fù)載要在兩個系統(tǒng)上運行，這使得總工作負(fù)載翻了一倍。這些工作負(fù)載還要在不同的數(shù)據(jù)上執(zhí)行，以避免為解決沖突問題而導(dǎo)致的成本。在實際情況中，我們期望客戶設(shè)計自己的應(yīng)用程序來盡可能避免沖突，減少對性能的影響。 圖 7. 雙向映射和點對點映射對性能的影響 圖 8 采用與圖 4 相同的格式，它展示了每行所需的微秒數(shù)以及每一千個被復(fù)制的行每秒所需的 MIPS 這兩方面的處理器成本。 圖 8. 雙向映射和點對點映射對 CPU 和資源消耗的影響 下面是從這兩個圖中觀察到的一些方面：
在以往進(jìn)行的所有性能測試當(dāng)中，隨著工作負(fù)載和配置的不同，得到的結(jié)果會有很大的變化。您可能想知道，那些因素對于您對 Q 復(fù)制的中意程度會有怎樣的影響。下面是關(guān)于這些因素的影響力的考慮： 吞吐率 在本文中，我們一直選擇以每秒復(fù)制的行數(shù)來度量復(fù)制。當(dāng)然還有其他一些度量指標(biāo)，例如每秒的事務(wù)數(shù)，但是由于事務(wù)的復(fù)雜性變化多端，我們避免使用那個度量指標(biāo)作為通用的吞吐率度量。然而，事務(wù)的復(fù)雜性的確會影響每秒復(fù)制的行數(shù)。如前所述，大多數(shù)這方面的測試都使用在某些方面走極端（只有 INSERT），但在其他方面較為合理的工作負(fù)載：每個事務(wù)涉及 10 行，每個行 212 字節(jié)，并且共有 14 列。 圖 9 表明，改變這些參數(shù)將影響吞吐率（每秒的行數(shù)）。這個圖展示了當(dāng)每個事務(wù)的行數(shù)變化時（從 2 行/每個事務(wù)到至多 20 行/每個事務(wù)）取得的吞吐率，以及當(dāng)行的規(guī)模變化時（從 192 字節(jié)到 2K 字節(jié)）取得的吞吐率。從這個圖中可以看出，當(dāng)每個事務(wù)的行數(shù)增加時，每秒復(fù)制的行數(shù)也隨之增加。其原因是，復(fù)制需要開銷來處理每個行，另外還要開銷來處理每個事務(wù)。每秒有更多的事務(wù)意味著提交點更少了，因此開銷也就更小了。同樣，復(fù)制更多的數(shù)據(jù)（更大的行規(guī)模）會造成更大的工作量，并會減少每秒復(fù)制的行數(shù)。 圖 9. Q Capture 的吞吐率與行和事務(wù)的規(guī)模 延遲 在本文中，我們展示了一些很好的性能結(jié)果，在某些情況下，延遲甚至低于 1 秒。雖然在通過精心優(yōu)化的環(huán)境中，可以獲得這樣的結(jié)果，但還有一些因素很可能會使復(fù)制的真正延遲大于前面得到的值。這些因素包括：
有關(guān)這些監(jiān)控功能的更多信息，以及其他性能調(diào)優(yōu)方面的信息，請參閱在后面參考資料一節(jié)中列出的資料。 圖 10. 帶有 4 路數(shù)據(jù)共享的一個例子 當(dāng)然，有很多因素可能影響性能預(yù)期。結(jié)果在很大程度上取決于工作負(fù)載和配置的變化。雖然次秒級（sub-second）的延遲是可能達(dá)到的，但也無法保證。根據(jù)現(xiàn)今技術(shù)的標(biāo)準(zhǔn)，低于 5 秒的復(fù)制延遲仍然可以看作是突出情況，并且在大多數(shù)常見的 Q 復(fù)制場景中都是可以達(dá)到的。
本文中給出的測試是由硅谷實驗室 WebSphere Information Integration 的性能分析小組在 Q 復(fù)制的產(chǎn)品開發(fā)期間進(jìn)行的。有些測試是在采用尚未普遍可用的產(chǎn)品代碼級的情況下進(jìn)行的。 測試人員有意地使工作負(fù)載對 Q 復(fù)制施加盡可能大的壓力，同時減少硬件資源。因此，大多數(shù)測試只包含數(shù)據(jù)庫 INSERT。（由于現(xiàn)實情況下工作負(fù)載同時還會包含應(yīng)用程序處理和 SELECT，因此，用于這種 INSERT 工作負(fù)載的復(fù)制部分所消耗的資源可能遠(yuǎn)遠(yuǎn)多于客戶預(yù)計在類似系統(tǒng)上需要消耗的資源。） 對于 z/OS 測試，配置由下面各部分組成：
對于 AIX 測試，配置由以下部分組成：
雖然對于一個產(chǎn)品來說，取得良好的性能十分重要，但對于一個分析師而言，能夠?qū)π阅苓M(jìn)行監(jiān)控同樣具有重要意義。Q 復(fù)制提供了一些有用的功能，這些功能目前在 SQL 復(fù)制中是沒有的。也許最關(guān)鍵的是，現(xiàn)在可以測量 Q 復(fù)制取得的端到端事務(wù)的延遲。Replication Center 提供了對 Q Capture 和 Q Apply 的報告，其中包括以下度量指標(biāo)：
此外，性能統(tǒng)計信息是在監(jiān)控表（CAPMON、CAPQMON 和 APPLYMON）中維護(hù)的，其他監(jiān)控軟件可以查詢這些表。 在參考資料一節(jié)中可以找到有關(guān)這些監(jiān)控功能的更多信息，以及大量其他性能調(diào)優(yōu)方面的信息。
我們相信，Q 復(fù)制使數(shù)據(jù)庫復(fù)制技術(shù)有了顯著的進(jìn)步，某些方面要強(qiáng)于 SQL 復(fù)制。在一個測試環(huán)境中，我們發(fā)現(xiàn)：
這些性能上的提高，以及其他功能上的增強(qiáng)，使您可以更好地利用數(shù)據(jù)庫復(fù)制來滿足您的業(yè)務(wù)需要。
Q 復(fù)制開發(fā)和性能小組的很多成員都為本文中的材料作出了貢獻(xiàn)，他們是 John Aschoff、Nhut Bui、Ying Chang、Nguyen Dao 和 Beth Hamel。如果您對于本文有什么疑問和評論，可以發(fā)送郵件給 John Aschoff（aschoffj@us.ibm.com）。
(1) MIPS = Million Instructions per Second（每秒的百萬指令數(shù)），這是用于評價大型主機(jī)處理器的相對速度的粗略方法。在這些實驗中用到的 4 個處理器中，每個處理器的速度大約是 200 MIPS。MIPS 是對相對速度的非常粗略的度量方法。 (2) 這里用于計算每行所需微秒數(shù)的技術(shù)，以觀察到的每行所需的總處理器時間在組成該系統(tǒng)的 4 個處理器上分?jǐn)偟玫降臅r間為依據(jù)。該技術(shù)的優(yōu)點在于，它可以捕捉所有花費的時間，但缺點是當(dāng)對處理器的使用量比較少時，由于“低使用量的影響”，它可能會有些夸張。在 Q 捕獲方面，每行被扣除掉了 100 微秒，因為這是在沒有復(fù)制的純 INSERT 工作負(fù)載的情況下觀察到的成本。所需的 MIPS 數(shù)嚴(yán)格地以觀察這種 200 MIPS 處理器得到的一組結(jié)果為依據(jù)。 (3) 本文中大多數(shù)其他的 z/OS 測試都使用 4-處理器的 LPAR。 (4) 這種工作負(fù)載配置不是為發(fā)現(xiàn)最大吞吐率而設(shè)計的，而是為了可以通過相同的工作負(fù)載需求來比較各種不同的方案。結(jié)果，我們有意地在事務(wù)之間引入了一個較短的延遲（9 微秒）。 (5) 在計算每行的成本時，我們將 CPU 成本除以每個系統(tǒng)上捕捉到的并被應(yīng)用的總行數(shù)。 (6) 光和電也只能那么快！
本文包含的信息是在“現(xiàn)狀”的基礎(chǔ)上提供的，沒有經(jīng)過任何形式的 IBM 測試。該信息的使用或這些技術(shù)的實現(xiàn)是用戶的責(zé)任，可以依靠用戶的能力進(jìn)行評估，并將其集成到客戶特有的操作環(huán)境中。雖然 IBM 已經(jīng)在特定情況下檢查了每一項的準(zhǔn)確性，但不保證在其他地方將獲得相同或相似的結(jié)果。嘗試調(diào)整這些技術(shù)以適應(yīng)自己環(huán)境的用戶必須自擔(dān)風(fēng)險。 本文顯示的性能信息數(shù)據(jù)基于一個測試環(huán)境中所獲得的結(jié)果。受各種因素的影響，各項結(jié)果和性能可能有所變化。有關(guān)本文中使用的工作負(fù)載和配置的更多信息，可以在“工作負(fù)載和配置”一節(jié)中找到。
| ||||||||||||||||||||||||||||||||||||||||||||||||||
