很多線上交易的作業不容許等待,例如股票交易、電話費率計算、線上的訂票服務,或者客服系統。如果等待時間過長,或者客戶總是買不到想要的東西,滿意度就會往下掉。如果你對系統的反應時間要求嚴苛,而且發現效能瓶頸總是卡在資料往返磁碟的存取過程,不妨考慮記憶體資料庫,它可以提升6~20倍的存取效率。

少了硬碟瓶頸,資料存取大躍進
當記憶體的價格越來越平易近人,IT人員不用為了記憶體空間的運用錙銖必較,市面上也出現記憶體資料庫這類解決方案,使資料的存取省掉磁碟存取過程,效能因此加速6~20倍

徹底了解IBM與Oracle記憶體資料庫解決方案的差異
兩家的解決方案在基礎設計架構上差異不大,同樣有快取及單機兩種模式,也都提供Hot Standby備援機制。主要差異在後端串連資料庫的開放性

該用記憶體資料庫嗎?
記憶體資料庫同樣有完整的備份與復原方案,所以需考量的是調整架構的軟、硬體成本少了硬碟瓶頸,資料存取大躍進

在硬體快速發展的情況下,記憶體的容量與處理器運算速度,以超越想像的發展大幅成長,價格也越來越便宜。過去在記憶體的容量少、價格高的時候,資料庫的應用,為了善用有限的記憶體空間,系統只能把需要使用的資料上載到記憶體,待資料處理完成之後,便釋放記憶體空間供給其他系統使用。

然而,時至今日,記憶體的取得越來越便宜,無論個人電腦或是伺服器,動輒都有數GB甚至數十GB的記憶體。這樣的變化也使得軟體運作的模式隨之改變。

由於記憶體和處理器不再是執行效能的主要瓶頸,磁碟的存取(Disk I/O)和網路反而成了拖慢效能的最大元兇。於是記憶體資料庫(In Memory Database)應運而生,它與傳統的關聯式資料庫相同,採用SQL語法、可以撰寫預存程序,提供索引、備份、復原及備援等所有關聯式資料庫具備的管理機制,也會產生快照檔(Checkpoint File)及交易日誌檔(Transaction Log)。

當企業可以把資料直接放到記憶體進行存取與計算,少了存取磁碟的往返過程,效能比起傳統的資料庫(Disk Based Database)足足快上6~10倍。

當資料存取效能影響獲利,加速就是必要
事實上,資料庫的發展已經相當成熟,企業只要搭配足夠等級的硬體設備,系統的存取效能已能滿足多數應用的要求。尤其對於內部的使用者而言,就算需要等個幾秒鐘,也是可以容許的範圍。

然而,對於即時交易型的應用就另當別論,差個幾秒影響所及,不是「等一下」的時間差而已。尤其是電信及金融產業,他們也是採用記憶體資料庫的第一批客戶。

以股票與期貨的電子下單為例,是分秒必爭的交易,客戶在乎的是「成交與否」與「價格高低」,因為有沒有買到、成交價格多少,直接影響到投資的利益。所以客戶對於系統下單的效率,要求比較嚴苛。

再者,以運動彩券為例,使用者下注某位球員、比數及賠率等都是關注的焦點,慢個幾秒可能就是「賺」和「賠」的不同結局了。這些是資料庫的存取效率有明顯影響的案例。

再就企業角度而論,電信產業的易付卡應用,餘額的計算對於企業而言是效能要求相當嚴苛的應用。電信公司不可能讓客戶在餘額扣光之後,還毫無限制地通話。所以當易付卡用戶開始撥打電話,系統就要持續地計算扣款金額、比對帳戶餘額,當餘額低於下限的時候,例如只剩50元,必須要發出訊息提醒使用者。

另一種應用是針對客戶服務部門。事實上,客戶在電話線上等待操作人員回覆的時間,與企業的服務形象正相關,同時也影響仍在線上等待接聽的客戶數量。尤其特定領域的客戶服務部門,例如銀行的信用卡、帳單的查詢或者與產品銷售相關的電話服務,動輒數百位客服人員在線上接聽電話,當客服人員接聽電話時,要能夠馬上調出客戶的資料,以因應後續的諮詢與處理。

另外,臺灣高科技製造業生產線的監控作業,需要五分鐘計算一次良率並產出報表,因此目前也有採用記憶體資料庫的企業。臺灣澳圖美德資訊長杜奕鋒解釋:「如果資料庫存取的效能存在瓶頸,可能發生上一個五分鐘的良率還沒算完,下一個五分鐘的良率又要開始計算的情況。」

這類的報表問題在其他產業也有不同程度的瓶頸,許多企業運用晚上資料庫的離峰時間,設定排程做一些運算或產出報表,然而當某一個排程因為各種因素而未成功執行,隔天的作業可能就大受影響。

傳統的解決方式──快取
在沒有記憶體資料庫之前,針對磁碟存取造成拖慢資料庫效能的瓶頸,資訊部門已衍生一些因應的方式。

就以上述所舉高科技製造業的良率計算為例,過去的作法是每5分鐘產生一個快照檔(Checkpoint File),丟到另一臺主機專門應付報表用途。然而額外建置伺服器的軟、硬體及儲存設備的成本頗高。
而多數企業比較可能採取的技巧是──增加記憶體,然後用各種快取(Cache)技巧提升效能。

在資料庫方面,企業可以把使用者經常查詢的資料上載到記憶體,以加速查詢的效能。快取的設計方式有很多種,例如當使用者查詢某一筆資料時,把時間相近或者順序相近的其他資料,連帶也快取到記憶體,那麼如果下次查詢的資料落在快取的範圍中,就不用再回磁碟去找資料。

這樣的作法,可以增加快取擊中率(Cache Hit Rate),如果資料量不大或者記憶體容量足夠,企業甚至可以選擇把特定幾個使用者經常查詢的資料表(Table)整個上載到記憶體。然而,企業需要快取的資料通常有一定的規模,所以擊中率未必能夠達到百分之百,當使用者需要的資料不在記憶體中,仍需存取磁碟。

還有一個加速查詢的方式,是將查詢結果製作成網頁。有一些Web應用,不同使用者查詢的結果大同小異,那麼開發者可撰寫程式,事先把查詢結果製作成網頁,所以使用者查詢的是早已產生好的網頁,即省掉資料庫重複存取造成的負擔。

這麼做的先決條件,是查詢結果的變異性不大,資料可能間隔數小時或數天之後,才會有所變化,那麼就可以考慮以這種方式處理。
當然,快取的技巧已經不只應用在資料層面,現在連程式及物件也有快取的解決方案。像是Oracle的Coherence及開放源碼的JCACHE及OSCache,用意都是把常用的功能或物件快取在記憶體以加速效能的設計。


快取擊中率(Cache Hit Rate)

就處理器而言,所謂的「快取(Cache)」,是指處理器架構中的「高速緩衝儲存器」,它位於處理器與記憶體之間。由於處理器的執行效能優於主記憶體,所以用快取來暫存可能頻繁存取的指令或資料,用以縮短存取 記憶體的時間。

而「快取擊中率」,指的是快取中暫存的資料是剛巧符合處理器需求的比例。例如處理器所需讀取的資料,100次中有70次在快取內找得到,便表示快取擊中率是70%。


而就軟體領域而言,「快取」指的就是記憶體。以應用程式為例,當記憶體發展到一個程度,開發者假定使用者的電腦有更大的容量可以存放資料,就會調整設計方式。例如文書或影像處理軟體,它們將更多的資料上載至記憶體,如此一來使用者存取資料時,快取擊中率便提高。


同樣的,資料庫應用也因為記憶體急速發展而有所改變,當使用者運用各種快取技巧,把使用者可能用到的資料上載至記憶體,便增 加了快取擊中率,也減少磁碟存取的機會。



記憶體資料庫與傳統資料庫相較,效能提升6~20倍
就資料的存取加速而言,無論是快取資料於記憶體,或事先產出結果頁的方式,加速的部分,其實僅在「查詢」層面。一旦使用者觸發「寫入」的行為,例如透過電子下單買/賣商品,快取的設計就發揮不了作用,系統仍需寫入資料至硬碟。

也就是說,針對「讀取」和「寫入」行為都很頻繁的應用,快取的作法幫助有限。唯有整個資料庫都搬到記憶體上運行,讀取和寫入資料的速度才能明顯加快。

加快多少呢?

根據Oracle針對自家記憶體資料庫TimesTen所做的測試,讀取1筆資料需要的時間是5微秒,也就是說1秒鐘可以查詢20萬筆資料;而更新一筆資料則需15微秒,等於是1秒鐘可以更新6.67萬筆資料。

對照專門測試IT產品並計算性價比的TPC(Transaction Processing Performance Council),在2009年以不同廠牌伺服器測試Oracle 11G標準版資料庫的存取效能,最佳的存取效能記錄是每秒完成10654.37筆交易,所謂「交易」有可能是查詢或者更新行為。

兩相對照起來,TimesTen 11G和Oracle 11G的存取效能有6~20倍的差距。

而IBM在相同軟硬體環境下,測試自家SolidDB和DB2的存取效能,更新資料SolidDB快5.26倍,而查詢資料的效能,SolidDB則快了19.27倍,也差不多是這樣的比例。

一般而言,資料庫應用通常是查詢的次數遠高於更新的頻率,以線上交易為例,使用者通常是廣泛地查詢各類商品後,才選定商品下單購物。在這樣的行為模式之下,記憶體資料庫對於存取效能的幫助更加明顯。

引擎針對記憶體特性最佳化,讀取效能比快取更好
記憶體資料庫在市場已經有幾年的時間,不過臺灣IT界對這類產品的熟悉度有限。事實上,就IBM和Oracle推出的解決方案而言,它就是一個運行於記憶體的關聯式資料庫,可以單機運行,或者建置在傳統資料庫的前端。

對於熟悉關聯式資料庫的IT人而言,導入記憶體資料庫的學習門檻並不高。

那麼記憶體資料庫何以能超越傳統資料庫,提供快6至20倍的效能呢?首要原因是它把資料存放於記憶體,因此省去往返磁碟讀寫資料的過程,克服I/O的瓶頸。

其次,企業就算利用快取機制,把讀取頻繁的資料表甚至整個資料庫都上載到記憶體,仍舊不敵記憶體資料庫的讀取效能。原因在於,記憶體資料庫調整了演算法,它的引擎已針對記憶體的特性做了最佳化的處理。

交易日誌檔存於硬碟,關機資料不漏失
即使記憶體資料庫有優異的效能,不過很多臺灣企業沒聽說過這方面的解決方案。而相關解決方案廠商最需要努力的方向,是IT人對於資料存放於記憶體的信任程度。

硬碟畢竟是比較可以信賴的儲存設備,記憶體在一般的觀念中,屬於暫存資料的設備,伺服器一旦關機,資料將隨之消失。更不用說一個打雷、閃電或是供電不穩,記憶體就有可能發生漏失資料的情況。

事實上,相關廠商也了解這方面可能造成的問題,以IBM和Oracle的記憶體資料庫而言,為確保資料的完整性,快照資料庫的Checkpoint File和記錄每筆交易的Transaction Log,仍舊是存放於硬碟,當資料有所漏失或者發生伺服器需要關機重啟的情況,透過本身系統硬碟中的快照集和交易日誌,可復原資料庫至意外事件發生前的狀態。

當然,如果經費充足企業不妨選擇以兩臺主機搭配熱備援(Hot Standby)機制,當主要資料庫無法正常運行,自動由備援資料庫接手。

以IBM和Oracle記憶體資料庫的Hot Standby機制來說,在主要(Active)資料庫的伺服器出現異常狀況而無法正常運作時,系統會自動切換至備援(Standby)資料庫的那臺伺服器,接續線上的交易作業,使企業提供的服務不至中斷。

除此之外,備援資料庫還可分擔應用程式的查詢要求(Request),達到負載平衡的效果。

傳統的備援機制,在正常的狀態下,主要資料庫的任何異動,會透過Transaction Log將內容同步至備援資料庫。然而,除了同步資料,備援資料庫的資源幾乎是閒置的。

而目前兩家的記憶體資料庫解決方案,備援資料庫在預設情況下,不允許執行新增、修改及刪除資料的工作,但是可以處理讀取的要求,也就是說,它可以分擔來自應用程式的查詢需求。

快取模式下,記憶體資料庫的後端還有一個傳統資料庫
除此之外記憶體資料庫分為快取(Cache)及單機(Stand Alone)兩種運作模式。單機模式當然就是由記憶體資料庫獨立運行,藉由存放於硬碟的日誌及快照檔確保資料安全無虞。

不過,根據IBM和Oracle的經驗,多數企業選擇快取模式,畢竟不是所有的資料服務,都需要搭配極限的回應速度,資料全部都存放在記憶體資料庫的話,相對而言投資於記憶體的成本也會墊高。

而在快取模式下,記憶體資料庫只存放部分需要加速回應的資料表,而後端串連儲存資料於硬碟的傳統資料庫,前端記憶體資料庫的任何異動,會同步至後端的資料庫。若設計上前端的記憶體資料庫只提供查詢的機制,由後端資料庫負責處理資料的新增、刪除及修改,那麼後端的異動,也可同步至前端。



適合計算不複雜且高吞吐量的資料庫應用
記憶體資料庫加速存取的效果明顯,不過,並非所有的資料庫應用都適合,分析它的特性,我們歸納出有以下3種特徵的應用,適合採用此類解決方案:

● 對資料存取的反應時間(Response Time)要求嚴苛

● 交易吞吐量大

● 計算不複雜

綜合3項特性,杜奕鋒認為:「B2C的電子商務網站可以考慮記憶體資料庫解決方案。」目前電信及金融業在國內外都有導入的案例。以電信業為例,每年耶誕、元旦及春節的簡訊量,經常超出資料庫的負荷,若善用記憶體資料庫,便可以更即時地消化簡訊用戶的需求。

那麼,哪些情況不適合採用這類的解決方案呢?目前看來,包含複雜運算的商業智慧應用,未必適合採用記憶體資料庫,原因在於記憶體資料庫目前尚不支援MPP(Massive Parallel Processing,巨量平行處理)架構。

也就是說,一個SQL指令無法由多個處理器平行處理,所以運用記憶體資料庫執行大量資料的複雜運算,效益未必明顯,因為「處理器」有可能成為效能瓶頸。

此外,如果資料庫的交易行為需要跨多個資料表,而且這些資料表的資料量很大的話,企業勢必要把巨量的資料都上載到記憶體資料庫,那麼就得評估此類解決方案的性價比(性能/價格)是否划算。

再者,雲義科技研發部協理王建興表示舉例:「現今有許多大型網站,例如Facebook運用多臺伺服器建置一個叢集(Cluster),組成一個巨量的記憶體快取,以加速網站的存取。」也是可行。

不過,可以確定的是,雖然,記憶體資料庫的可靠性未必低於傳統資料庫,但它目前仍然難以完全取代傳統資料庫。杜奕鋒表示:「最終還是需要一個硬碟保存的版本。」

再者,就成本考量,記憶體的成本高於硬碟,所以就現階段的企業案例,大多應用記憶體資料庫存放即時性需求高的資料,並不會把所有資料移往記憶體,因為這麼做並不划算。

所以對於企業而言,到底是採購多臺機器並設計快取,還是在少數伺服器上充實記憶體數量,並搭配記憶體資料庫,何者是划算的選擇,得視應用而定。這方面企業得評估多方條件,精算自身適合的解決方案。


資料「In Memory」的設計已存在多年

現今仍有不少企業擔心記憶體資料庫的可靠性 ,然而這並不是一個很新的技術。事實上,在IBM與Oracle推出的記憶體資料庫之前,市面上早已存在其他搭配記憶體資料庫的應用或產品。

只不過它們搭配的資料庫,並非傳統的關聯式資料庫,而是採用專屬的資料格式,而「In Memory」的用意,無非是希望加速存取的效能。


例如,在香港有一家稱為「MemDB」的公司,設計者專門為中小企業開發會計、零售、庫存、條碼列印及客戶管理軟體。這家廠商設計了運行於記憶體的物件導向資料庫,用它來儲存中小企業的會計、商品及客戶等資料。


不過,MemDB並不單獨販售記憶體資料庫,而是設計在應用系統中,透過程式存取。


這麼做的優點,是對於中小企業而言,系統占用的空間不多,而且使用簡單。缺點則是目前IT人員普遍對物件導向資料庫並不熟悉,而且企業若未來希望移轉MemDB中的資料至關聯式資料庫,以便自行管理,必須尋求廠商的協助。


其次,商業智慧應用產品QlikView也有「In Memory」的概念,企業匯入QlikView的資料,是以專屬格式運行於記憶體,有效加速了分析與執行的速度,而且根據廠商提供的資訊,資料壓縮比為1:20,所以可以節省記憶體的空間使用量。不過,專屬格式也代表被平臺綑綁,未來若有分享資料或轉換平臺的需求,同樣需考量資料移轉的問題。


事實上,也有一些線上遊戲業者自行實作「In Memory」的資料處理模式。因為線上遊戲玩家的位移、地圖及個人資訊,有即時更新的需求,一場戰役可能數千人同時上線,因此資訊異動的頻率很高,任何經驗值的變動都會影響戰役的勝敗。對廠商而言,記憶體化的資料存取才能應付如此巨量又即時性的需求。


這些例子顯示記憶體中的資料存取應用,已在各領域出現。只是評估解決方案時,是延續關聯式資料庫應用的產品,還是自行開發或者選擇格式專屬的封閉產品,是企業必須考量的重點。

徹底了解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」狀態,不過,針對不同來源同時更新同一筆資料的衝突管理,管理者就必須手動設定管理原則。

不同之處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原廠表示,由於資料庫傳送單筆資料的訊息量很小,所以對效能的影響並不明顯。

該用記憶體資料庫嗎?

企業對於記憶體資料庫的常見疑慮在於:資料儲存在記憶體中安全嗎?斷電時怎麼辦?事實上,你還有一份足供備援的Transaction Log檔儲存於硬碟,所以並不需要擔心資料會消失。
其他問題如:備份機制為何?使用的語法還是SQL嗎?改寫系統的主要負擔何在?還有,使用上划算嗎?關於這些問題,這裡都有完整的回答。

Q1一旦斷電,資料就不見了?
這是目前大部分企業面對記憶體資料庫的最大疑慮,尤其記憶體的可信賴度遠低於硬碟。

然而記憶體資料庫除了儲存資料於記憶體,也有記錄檔存放於硬體,所以可以避免資料漏失的情況發生。

若是採用快取模式,記憶體資料庫的角色則類似「快取(Cache)」,所以相同的內容會同步到後端的傳統資料庫(Disk- based Database)。而即使在單機模式下也不用擔心,因為記憶體資料庫的交易日誌檔(Transaction Log)和快照檔(Checkpoint File)仍是儲存於硬碟,所以可以透過這些檔案復原。

Checkpoint File主要的作用是依管理者的設定,每隔一段時間對資料庫做一次快照(Snapshot),儲存資料庫當時的樣子,管理者可以利用快照集還原資料庫在某一個時間點的內容。

而記憶體資料庫在發生電腦當機或斷電的情況,在重新啟動時便透過Checkpoint File還原資料庫至最近一次快照的狀態,而從快照那個時間點到當機前的異動,則搭配Transaction Log填補,如此便可還原至斷電前的狀態。

以上是補救資料的方法,不過,相較於此,企業更在意的是線上作業停擺。

關於這方面,IBM和Oracle都推出Hot Standby的機制來因應。在正常的狀態下,主要(Active)資料庫透過Transaction Log將交易同步至備援(Standby)資料庫。除此之外,備援資料庫還可分擔應用程式的查詢要求(Request),達到負載平衡的效果。

而當系統偵測到主要資料庫的運作發生異常,即自動切換到備援資料庫,接續線上的交易作業,管理者不需要手動設定或重新啟動電腦。



Q2在快取模式下,如果記憶體資料庫和後端的傳統資料庫斷線,系統如何處理?
若在記憶體資料庫的後端串連傳統資料庫,前後端雙方的資料同步,主要還是根據Transaction Log的內容。所以,即使發生斷線的狀況,主機恢復連線時,仍可透過Transaction Log補齊斷線階段異動資料。

這部分由於TimesTen的Transaction Log已調整成與Oracle資料庫相同的格式,所以兩者的資料同步沒有困難,管理者甚至可以設定逐筆更新或者定時批次處理。

而IBM則採取開放策略,SolidDB的後端可串連多種廠牌的資料庫,而資料的同步由CDC(Change Data Capture)機制處理,它自動轉換Transaction Log的內容,以符合各廠牌資料庫的格式,達到同步的目的。

Q3與其建置記憶體資料庫,何不擴充記憶體就好?
單純把記憶體放大的作法,與記憶體資料庫相較,存取效率還是會有數倍的差距。

傳統應用記憶體快取的作法,是把讀取機率比較高的資料,快取在記憶體,如此一來,可以增加查詢的Hit Rate(擊中率),減少磁碟存取(Disk I/O)的機會。事實上,依據資料庫的設計原理,在一般情況下,使用者查詢一筆資料,資料庫通常會連帶把該筆資料前後的資料,也一併快取在記憶體,方便後續的查詢使用。

然而使用者下一次的查詢,若未在快取的範圍之內,仍必須回硬碟查詢。再加上,使用者若有「寫入」的動作,勢必得將異動更新到實體資料庫,所以尤其是針對寫入動作頻繁的資料庫應用,增加記憶體以提升存取效能的作法,效果有限。

再者,記憶體資料庫的引擎,與傳統資料庫的設計有所不同,甲骨文大中華區臺灣技術諮詢部資深諮詢經理黃久安表示:「傳統資料庫找資料的方式,需要比較多的判斷。」而記憶體資料庫已針對記憶體的特性,做了最佳化的處理,所以效能優於資料庫搭配更大記憶體快取容量的作法。

Q4它的查詢語法與傳統資料庫有差別嗎?
就IBM和Oracle提出的記憶體資料庫方案而論,他們本身都是典型的關聯式資料庫,差別僅在於存取與執行的載體,是記憶體而非硬碟。

所以,也同樣採用SQL語法,對於熟悉關聯式資料庫應用的IT人,沒有太大的學習門檻。

不過,記憶體資料庫仍無法避免傳統資料庫存在的各家SQL語法有小差異的情況。這方面IBM SolidDB遵循ANSI SQL-92標準,而Oracle TmesTen則採用Oracle PL/SQL。

Q5既有系統若改採記憶體資料庫,主要的負擔何在?
無論採取快取或單機模式的記憶體資料庫,架構調整與程式的修改是主要的工作,哪些資料表需要藉助記憶體資料庫強化存取的效能,必須定義出來的。

架構面的調整方式與成本有關,如果資料量很大的話,整個資料庫改成記憶體資料庫的成本很高。

就資料庫的成本來看,根據廠商提供的建議售價,Oracle Standard版是5,800美元/處理器、Enterprise版的售價是47,500美元/處理器,TimesTen的售價是14,500美元/處理器。而IBM SolidDB的售價大致上是35,300美元/100 Processor Value Unit(PVU),而PVU的算法又與伺服器及處理器的等級有關。

大致上看來,記憶體資料庫的售價有可能高於傳統資料庫。再加上,伺服器的記憶體價格高於個人電腦。所以資料量、記憶體、資料庫授權如何搭配的性價比最高,企業需要進一步精算。

確立架構之後,畫出程式改寫的範圍。當架構改變,資料庫連結必須隨之調整。而就IT人員而言,程式的改寫是最主要的負擔。

臺灣澳圖美德資訊長杜奕鋒分析:「傳統寫SQL語法,為了避免Disk I/O,會盡量減少磁碟存取的次數。而在記憶體資料庫中,因為磁碟導致的瓶頸因素消失,SQL的寫法或多或少會有不同。」

尤其各家資料庫的SQL語法有小差異,所以程式及SQL的改寫是免不了的。這方面原先即採用Oracle的企業,導入TimesTen的負擔會小一點,因為兩者都採用PL/SQL,不用調整SQL語法。而選擇SolidDB則有不被特定資料庫平臺綑綁的好處。

熱門新聞

Advertisement