OLTP與OLAP比較

OLTP與OLAP的介紹

    資料處理大緻可以分成兩大類：聯機事務處理OLTP（on-line transaction processing）、聯機分析處理OLAP（On-Line Analytical Processing）。OLTP是傳統的關系型資料庫的主要應用，主要是基本的、日常的事務處理，例如銀行交易。OLAP是資料倉庫系統的主要應用，支援複雜的分析操作，側重決策支援，并且提供直覺易懂的查詢結果。 

OLTP  系統強調資料庫記憶體效率，強調記憶體各種名額的指令率，強調綁定變量，強調并發操作；

OLAP  系統則強調資料分析，強調SQL執行市場，強調磁盤I/O，強調分區等。 

OLTP與OLAP之間的比較：   

     OLTP，也叫聯機事務處理（Online Transaction Processing） ，表示事務性非常高的系統，一般都是高可用的線上系統，以小的事務以及小的查詢為主，評估其系統的時候，一般看其每秒執行的Transaction以及Execute SQL的數量。在這樣的系統中，單個資料庫每秒處理的Transaction往往超過幾百個，或者是幾千個，Select 語句的執行量每秒幾千甚至幾萬個。典型的OLTP系統有電子商務系統、銀行、證券等，如美國eBay的業務資料庫，就是很典型的OLTP資料庫。

OLTP系統最容易出現瓶頸的地方就是CPU與磁盤子系統。

（1）CPU出現瓶頸常表現在邏輯讀總量與計算性函數或者是過程上，邏輯讀總量等于單個語句的邏輯讀乘以執行次數，如果單個語句執行速度雖然很快，但是執行次數非常多，那麼，也可能會導緻很大的邏輯讀總量。設計的方法與優化的方法就是減少單個語句的邏輯讀，或者是減少它們的執行次數。另外，一些計算型的函數，如自定義函數、decode等的頻繁使用，也會消耗大量的CPU時間，造成系統的負載升高，正确的設計方法或者是優化方法，需要盡量避免計算過程，如儲存計算結果到統計表就是一個好的方法。

（2）磁盤子系統在OLTP環境中，它的承載能力一般取決于它的IOPS處理能力. 因為在OLTP環境中，磁盤實體讀一般都是db file sequential read，也就是單塊讀，但是這個讀的次數非常頻繁。如果頻繁到磁盤子系統都不能承載其IOPS的時候，就會出現大的性能問題。

    OLTP比較常用的設計與優化方式為Cache技術與B-tree索引技術，Cache決定了很多語句不需要從磁盤子系統獲得資料，是以，Web cache與Oracle data buffer對OLTP系統是很重要的。另外，在索引使用方面，語句越簡單越好，這樣執行計劃也穩定，而且一定要使用綁定變量，減少語句解析，盡量減少表關聯，盡量減少分布式事務，基本不使用分區技術、MV技術、并行技術及位圖索引。因為并發量很高，批量更新時要分批快速送出，以避免阻塞的發生。 

OLTP 系統是一個資料塊變化非常頻繁，SQL 語句送出非常頻繁的系統。 對于資料塊來說，應盡可能讓資料塊儲存在記憶體當中，對于SQL來說，盡可能使用變量綁定技術來達到SQL重用，減少實體I/O 和重複的SQL 解析，進而極大的改善資料庫的性能。

    這裡影響性能除了綁定變量，還有可能是熱快（hot block）。 當一個塊被多個使用者同時讀取時，Oracle 為了維護資料的一緻性，需要使用Latch來串行化使用者的操作。當一個使用者獲得了latch後，其他使用者就隻能等待，擷取這個資料塊的使用者越多，等待就越明顯。 這就是熱快的問題。 這種熱快可能是資料塊，也可能是復原端塊。 對于資料塊來講，通常是資料庫的資料分布不均勻導緻，如果是索引的資料塊，可以考慮建立反向索引來達到重新分布資料的目的，對于復原段資料塊，可以适當多增加幾個復原段來避免這種争用。 

     OLAP，也叫聯機分析處理（Online Analytical Processing） 系統，有的時候也叫DSS決策支援系統，就是我們說的資料倉庫。在這樣的系統中，語句的執行量不是考核标準，因為一條語句的執行時間可能會非常長，讀取的資料也非常多。是以，在這樣的系統中，考核的标準往往是磁盤子系統的吞吐量（帶寬），如能達到多少MB/s的流量。

    磁盤子系統的吞吐量則往往取決于磁盤的個數，這個時候，Cache基本是沒有效果的，資料庫的讀寫類型基本上是db file scattered read與direct path read/write。應盡量采用個數比較多的磁盤以及比較大的帶寬，如4Gb的光纖接口。

在OLAP系統中，常使用分區技術、并行技術。

    分區技術在OLAP系統中的重要性主要展現在資料庫管理上，比如資料庫加載，可以通過分區交換的方式實作，備份可以通過備份分區表空間實作，删除資料可以通過分區進行删除，至于分區在性能上的影響，它可以使得一些大表的掃描變得很快（隻掃描單個分區）。另外，如果分區結合并行的話，也可以使得整個表的掃描會變得很快。總之，分區主要的功能是管理上的友善性，它并不能絕對保證查詢性能的提高，有時候分區會帶來性能上的提高，有時候會降低。

    并行技術除了與分區技術結合外，在Oracle 10g中，與RAC結合實作多節點的同時掃描，效果也非常不錯，可把一個任務，如select的全表掃描，平均地分派到多個RAC的節點上去。

    在OLAP系統中，不需要使用綁定（BIND）變量，因為整個系統的執行量很小，分析時間對于執行時間來說，可以忽略，而且可避免出現錯誤的執行計劃。但是OLAP中可以大量使用位圖索引，物化視圖，對于大的事務，盡量尋求速度上的優化，沒有必要像OLTP要求快速送出，甚至要刻意減慢執行的速度。

    綁定變量真正的用途是在OLTP系統中，這個系統通常有這樣的特點，使用者并發數很大，使用者的請求十分密集，并且這些請求的SQL 大多數是可以重複使用的。

    對于OLAP系統來說，絕大多數時候資料庫上運作着的是報表作業，執行基本上是聚合類的SQL 操作，比如group by，這時候，把優化器模式設定為all_rows是恰當的。 而對于一些分頁操作比較多的網站類資料庫，設定為first_rows會更好一些。 但有時候對于OLAP 系統，我們又有分頁的情況下，我們可以考慮在每條SQL 中用hint。 如：

    Select  a.* from table a;

分開設計與優化

    在設計上要特别注意，如在高可用的OLTP環境中，不要盲目地把OLAP的技術拿過來用。

    如分區技術，假設不是大範圍地使用分區關鍵字，而采用其它的字段作為where條件，那麼，如果是本地索引，将不得不掃描多個索引，而性能變得更為低下。如果是全局索引，又失去分區的意義。

    并行技術也是如此，一般在完成大型任務時才使用，如在實際生活中，翻譯一本書，可以先安排多個人，每個人翻譯不同的章節，這樣可以提高翻譯速度。如果隻是翻譯一頁書，也去配置設定不同的人翻譯不同的行，再組合起來，就沒必要了，因為在配置設定工作的時間裡，一個人或許早就翻譯完了。

    位圖索引也是一樣，如果用在OLTP環境中，很容易造成阻塞與死鎖。但是，在OLAP環境中，可能會因為其特有的特性，提高OLAP的查詢速度。MV也是基本一樣，包括觸發器等，在DML頻繁的OLTP系統上，很容易成為瓶頸，甚至是Library Cache等待，而在OLAP環境上，則可能會因為使用恰當而提高查詢速度。

    對于OLAP系統，在記憶體上可優化的餘地很小，增加CPU 處理速度和磁盤I/O 速度是最直接的提高資料庫性能的方法，當然這也意味着系統成本的增加。      

    比如我們要對幾億條或者幾十億條資料進行聚合處理，這種海量的資料，全部放在記憶體中操作是很難的，同時也沒有必要，因為這些資料快很少重用，緩存起來也沒有實際意義，而且還會造成實體I/O相當大。 是以這種系統的瓶頸往往是磁盤I/O上面的。

    對于OLAP系統，SQL 的優化非常重要，因為它的資料量很大，做全表掃描和索引對性能上來說差異是非常大的。

其他

     Oracle 10g以前的版本建庫過程中可供選擇的模闆有 ：

        Data Warehouse （資料倉庫）

        General Purpose  （通用目的、一般用途）

        New Database

        Transaction Processing  （事務處理）

     Oracle 11g的版本建庫過程中可供選擇的模闆有 ：

        一般用途或事務處理

        定制資料庫

        資料倉庫

個人對這些模闆的了解為：

     聯機分析處理（OLAP,On-line Analytical Processing），資料量大，DML少。使用資料倉庫模闆

     聯機事務處理（OLTP,On-line Transaction Processing），資料量少，DML頻繁，并行事務處理多，但是一般都很短。使用一般用途或事務處理模闆。

     決策支援系統（DDS，Decision support system)，典型的操作是全表掃描，長查詢，長事務，但是一般事務的個數很少，往往是一個事務獨占系統。

轉自：http://blog.csdn.net/rfb0204421/article/details/6873284

            http://76287.blog.51cto.com/66287/885475