少了硬碟瓶頸，資料存取大躍進

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

然而，時至今日，記憶體的取得越來越便宜，無論個人電腦或是伺服器，動輒都有數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％。

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

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

 記憶體資料庫分為快取及單機兩種模式 

IBM和Oracle 的記憶體資料庫，都提供快取（Cache）和單機（Stand Alone）兩種應用模式。快取模式的記憶體資料庫，後端仍串連儲存資料於硬碟的傳統資料庫；而單機模式的記憶體資料庫則獨立運行。

記憶體資料庫與傳統資料庫相較，效能提升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的瓶頸。

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

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

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

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

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

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

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

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

事實上，也有一些線上遊戲業者自行實作「In Memory」的資料處理模式。因為線上遊戲玩家的位移、地圖及個人資訊，有即時更新的需求，一場戰役可能數千人同時上線，因此資訊異動的頻率很高，任何經驗值的變動都會影響戰役的勝敗。對廠商而言，記憶體化的資料存取才能應付如此巨量又即時性的需求。
這些例子顯示記憶體中的資料存取應用，已在各領域出現。只是評估解決方案時，是延續關聯式資料庫應用的產品，還是自行開發或者選擇格式專屬的封閉產品，是企業必須考量的重點。

交易日誌檔存於硬碟，關機資料不漏失

即使記憶體資料庫有優異的效能，不過很多臺灣企業沒聽說過這方面的解決方案。而相關解決方案廠商最需要努力的方向，是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），組成一個巨量的記憶體快取，以加速網站的存取。」也是可行。

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

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

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

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