徹底了解IBM與Oracle記憶體資料庫解決方案的差異

目前關聯式資料庫中，已正式推出記憶體資料庫解決方案的廠商，包括IBM的SolidDB及Oracle TimesTen，兩者的功能及架構大同小異。

主要的不同是IBM SolidDB支援串連多種異質資料庫，Oracle則限自家產品。SolidDB的開放性讓企業的選擇性更多，然而另一個層面也代表異質資料庫之間的語法差異，也會使開發及改寫的成本較高。Oracle因支援資料庫的限定，沒有這方面的負擔。

相同之處：都有兩種模式可應用，並具備提升可靠度的機制

這兩家的解決方案，都分為快取及單機兩種模式。快取是比較多企業採取的策略，把需要加快存取速度的資料置於記憶體資料庫，而其他沒有即時性需求的部分，仍存放在傳統資料庫。而且他們都有Hot Standby，能提供企業高可用性的記憶體資料庫解決方案。

有快取及單機兩種應用模式可選擇

雖然Oracle和IBM提供快取（Cache）及單機（Stand Alone）兩種選擇，但目前多數的企業案例以前者為主。在快取模式下，記憶體資料庫只存放即時性需求高的資料，而大多數的資料仍存放於後端的傳統資料庫。

以線上交易為例，前端的記憶體資料庫，存放與交易相關、有高速存取需要的資料，由於少了硬碟的效能瓶頸，可以提供使用者更快的回應速度（Response Time）。而記憶體資料庫中的異動，透過Transaction Log仍會同步到後端的傳統資料庫。

而單機模式下，記憶體資料庫是獨立運行的系統，如果整體資料庫的資料量不大，可以考慮這樣的架構。企業不用擔心發生無法預期的狀況，導致伺服器當機或需要重新啟動時，儲存在記憶體資料庫中的資料將隨關機而消失。事實上無論快取或單機的運作模式，系統都會將Transaction Log和Checkpoint File儲存於硬碟，所以系統在重新開機後，可以恢復資料庫至關機前的狀態。

Hot Standby可供負載平衡及故障復原

事實上，從硬碟「倒」資料至記憶資料庫，算是比較沒有效率的故障復原（Failover）方式，企業可以善用IBM和Oracle提供的Hot Standby機制，當主要（Active）記憶體資料庫的伺服器，因軟、硬體種種的原因而導致無法正常運行時，能自動切換至備援（Standby）記憶體資料庫，接續線上的交易作業，使服務不中斷。

Hot Standby機制除了故障復原的作用之外，還兼具負載平衡的作用。也就是當主要伺服器正常運作時，備援的記憶體資料庫並非閒置狀態，等待切換，它可分擔來自應用程式的查詢需求，這使備援的那臺伺服器可以分擔主要資料庫的部分流量與工作。

當然，若要達到真正的負載平衡，可以設定多臺資料庫同時為「Active」狀態，不過，針對不同來源同時更新同一筆資料的衝突管理，管理者就必須手動設定管理原則。

 運用CDC機制，SolidDB可串連多種資料庫 

IBM透過CDC（Change Data Capture）機制，使SolidDB可與各家資料庫互通。它的原理是經由Access Server，將SolidDB的Transaction Log，轉換成特定廠牌資料庫的Transaction Log格式，使SolidDB的資料能夠複製到各種廠牌的資料庫。不過，不限廠牌也表示企業必須適應遵循ANSI SQL-92的SolidDB與各家SQL語法之間的差異。

不同之處：IBM強調整合異質資料庫，Oracle較重視網格應用

分析兩家解決方案的不同之處，主要是IBM透過CDC（Change Data Capture）機制，使快取模式下，後端連接的資料庫沒有廠牌的限制。而Oracle則利用Cache Grid機制，使多臺TimesTen可以共享資料。

IBM的CDC機制使後端不限資料庫廠牌

相對於Oracle TimesTen的快取模式，限制只能搭配自家Oracle資料庫，IBM的SolidDB在最新6.3版，結合CDC（全名是InfoSphere Change Data Capture）機制，使後端可以串連各種廠牌的資料庫。

事實上，複製資料至異質資料庫的方式很多種，例如透過程式，設計資料同時寫入兩個資料庫。此外，也可以在資料庫中設定Trigger，當資料庫的內容發生任何異動，便自動觸發程式同步到另一個資料庫。然而，無論採用哪一種方案，都可能發生程式出問題或者資料庫「漏接」，導致資料庫內容不一致的情況。而且也會占用資料庫的資源。

而有了CDC 同步資料的好處，是透過Transaction Log異動資料，處理速度快，且耗用資源少。由於各家資料庫的Transaction Log格式都有一些差異，而透過CDC的運作，它介於SolidDB及後端資料庫之間，所以當任何一方資料有異動時，CDC的Access Server便解讀並轉換Transaction Log，成為目標資料庫可解讀的格式，達到資料同步的目的。

Oracle的Cache Grid架構，使記憶體資料庫可共享資料

Oracle TimesTen最新版11G推出的Cache Grid，也是有別於IBM的重要特色。Oracle一直致力於Grid（網格）的應用，在記憶體資料庫方面也不例外。在Cache Grid架構之下，TimesTen資料庫可以在各自獨立運行的情況下，又共享資料。

Cache Grid適合相同應用但資料區分成不同主機的情況。以證券交易為例，券商依北、中、南區因客戶不同而區分不同的交易資料庫，但是當原本南部的客戶經由北部的交易主機下單時，北部的資料庫會詢問Cache Grid下的所有資料庫，是否有該筆客戶資料，如果有的話，複製到本機並回覆應用程式。

記憶體資料庫加速了資料存取的速度，但Cache Grid架構下，資料若在別臺TimesTen中，透過網路傳輸會稍微折損效能。不過Oracle原廠表示，由於資料庫傳送單筆資料的訊息量很小，所以對效能的影響並不明顯。

 建立Cache Grid機制，使串連的TimesTen可共享資料 

Oracle以Grid的概念應用到記憶體資料庫，11G版允許多臺TimesTen主機串連起來，達到資料共享的目的。這麼做的前提是，資料庫限定Oracle自家的產品。

情境1：當應用程式經由TimesTen C查詢某筆資料（藍色方塊表示），而TimesTen C沒有這筆資料，透過Cache Grid機制，可以詢問其他串連的TimesTen資料庫是否有該筆資料，發現TimesTen A有該筆資料，則複製一份給TimesTen C，並回覆給應用程式。

情境2：應用程式經由TimesTen E查詢某筆資料（以綠色方塊表示），透過Cache Grid機制，發現後端的Oracle資料庫有該筆資料，則複製一份給TimesTen E，並回覆給前端的應用程式。

【相關報導請參考「記憶體資料庫存取效能提升6-20倍的祕密」】