目前關聯式資料庫中,已正式推出記憶體資料庫解決方案的廠商,包括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倍的祕密」】

熱門新聞

Advertisement