弄清楚你的業務類型——OLTP or OLAP

標籤：

在Oracle資料庫系統中，很多人沒有弄清楚自己的業務類型到底是什麼，就在開始盲目的尋求最佳化方法，而往往是把OLAP的方法使用在OLTP上，或者是OLTP的方法使用在OLAP上。這樣的使用，有的時候，對效能沒有任何的提高，甚至是大大的影響了效能，得到適得其反的效果。所以，在最佳化系統之前，弄清楚自己的業務類型。

1、什麼是OLTP
OLTP，也叫聯機交易處理(Online Transaction Processing)，表示事務性非常高的系統，一般都是高可用的線上系統，以小的事務以及小的查詢為主，評估其系統的時候，一般看其每秒執行的transaction以及execute sql的數量。在這樣的系統中，每秒處理的transaction往往超過幾百個，或者是幾千個，select 語句的執行量每秒幾千甚至幾萬個。典型的OLTP系統如電子商務系統，銀行，證卷等等，如美國ebay的業務資料庫，就是很典型的OLTP資料庫。
OLTP系統最容易出現的瓶頸就是CPU與磁碟子系統。cpu則取決於邏輯讀以及內部調用，如函數等等。一個執行頻繁的SQL語句，如果每個語句可以減少很少的邏輯讀，也相當於最佳化了一些邏輯讀很差的大型語句。很多人不感覺不到這裡的作用，覺得一個語句幾十個邏輯讀，執行時間基本為0，就不需要最佳化了，其實，只要他的執行次數非常頻繁，而且有最佳化的餘地，就一定要最佳化，如減少一定的邏輯讀或者降低執行次數，都是最佳化方法。
另外，一些計算性的函數，如sum，count，decode被非常頻繁的使用，也是非常消耗cpu的，我遇到一個系統，因為一個sql語句，大量的使用了sum與decode進行行列轉換，結果這一個語句就耗費了整個機器一半以上的CPU。
那麼，在一般的OLTP系統中，如果不考慮我上面說的函數問題，那麼，邏輯讀乘以執行次數，決定了cpu的消耗程度，如一個語句，每秒執行次數為500次，每個邏輯讀為15，但是，通過最佳化，能讓每個語句的邏輯讀從15降到10，那麼，每秒的邏輯讀就可以減少500*5=2500個，其實就是相當於最佳化了一個執行頻率為每秒1次，每次邏輯讀為2500個的語句（注意，2500個邏輯讀，在oltp系統是非常差的語句）。再如，假定一個1GHZ的cpu每秒能正常處理的邏輯讀是100,000個，如果是10個邏輯讀一個的語句，每秒可以處理10,000個，而1000個邏輯讀一個的語句，每秒則只能處理100個。
同以上道理，物理讀乘以執行次數，則決定了儲存子系統的處理能力，在一個OLTP環境中，物理讀一般都是db file sequential read決定的，也就是單塊讀，一個典型的OLTP系統，db file sequential read應當基本等於磁碟子系統的讀的IOPS。而磁碟子系統的IOPS處理能力，與cache命中率以及磁碟個數有很大的關係。我的一些文章中，也分析到了這些問題，如一個15K轉速的磁碟，每秒最多能處理的iops達到150個，基本就是極限了，如果cache不命中，那麼100個磁碟，最多能處理的IOPS僅僅是15000個（但是，實際上，還基本達不到這個值）。
OLTP最常用的技術就是cache技術與btree索引，cache決定了很多語句不需要從磁碟子系統獲得資料，所以，web cache與oracle data buffer對OLTP系統是很重要的。另外，在索引使用方面，語句是越簡單越好，這樣執行計畫也穩定，而且一定要使用綁定變數，減少語句解析，盡量減少關聯。其它方面，基本不使用分區技術，MV技術，並行技術以及位元影像索引，因為並發量很高，批次更新可能要盡量快速提交避免阻塞的發生。
在ebay的資料庫設計中，有一個很重要的點就是，資料庫只負責存放資料，商務邏輯盡量在業務層實現，因為資料庫擴充是困難的，而應用伺服器擴充是簡單的。其實，也就是說，在高可用的OLTP環境中，資料庫使用越簡單的功能越好。

2、什麼是OLAP
OLAP，也叫聯機分析(Online Analytical Processing)，有的時候也叫DSS決策支援系統，就是我們說的資料倉儲。在這樣的系統中，語句的執行量不是考核標準，因為一個語句的執行時間可能會非常長，讀取的資料也非常多。所以，這樣的系統中，考核的標準往往決定於磁碟子系統的輸送量。磁碟子系統的輸送量則直接取決於磁碟的個數，這個時候，cache基本是沒有效果的，這個時候資料庫的讀寫基本上是db file scattered read與direct path read/write。在我前面的一些文章中描述過，如果一個15K的磁碟的IO量每秒13M，那麼，100個磁碟，最多能提供的輸送量則是1300M/s（實際上，也基本達不到這個值）。如果磁碟個數足夠的話，還需要考慮採用比較大的頻寬，如4GB的光纖介面。
在OLAP系統中，常使用的技術有分區技術，並行技術。如分區技術可以使得一些大表的掃描變得很快（只掃描單個分區），而且方便管理。另外，如果分區結合并行的話，也可以使得整個表的掃描也會變得很快。並行技術除了與分區技術結合外，在oracle 10g中，與rac結合實現多節點的同時掃描，效果也非常不錯，把一個任務，如select的全表掃描，平均的指派到多個rac的節點上去。
在OLAP系統中，不需要使用綁定變數，因為整個系統的執行量很少，分析時間對於執行時間來說，可以忽略，而且避免出現錯誤的執行計畫。但是OLAP中可以大量使用位元影像索引，物化視圖，對於大的事務，盡量的尋求速度上的最佳化，沒有必要象OLTP需要快速提交，甚至要刻意減慢執行的速度。

3、總結
特別是在高可用的OLTP環境中，不要盲目的把OLAP的技術拿過來用，如分區技術，如果不是大範圍的使用了分區關鍵字作為where條件，而採用其它的欄位作為where條件，那麼，如果是本地索引，你將不得不掃描多個索引，而效能變的更為低下。如果是全域索引，那分區的意義又何在，只是多出一份分區技術的license而已。
並行技術也是如此，一般是在大型任務的時候才使用，好比說，實際生活中，一個比較大型的工作，如翻譯一本書，你可以先安排多個人，每個人翻譯不同的章節，這樣是可以提高翻譯速度，但是，你現在只是翻譯一頁，你也去分配不同的人翻譯不同的行，再組合起來，這個時間，你一個人或者早就翻譯完了。
位元影像索引在我前幾篇文章中有交代，如果用在oltp環境中，可能因為阻塞範圍太大，很容易阻塞與死結，但是，在olap環境中，可能會因為其特有的特性，提高olap的查詢速度。mv也是基本一樣，包括觸發器等等，在dml頻繁的oltp系統上，很容易成為瓶頸，而在olap環境上，則可能會因為使用恰當而提高查詢速度。

更多的差別與技術，細說下來太多了，有些東西，是要靠大家慢慢去體會的，我這裡也就不多說了，大家可以平常在自己的業務中多多體會。

 

oltp資料	olap資料
未經處理資料	匯出資料
細節性資料	綜合性和提煉性資料
當前值資料	曆史資料
可更新	不可更新，但周期性重新整理
一次處理的資料量小	一次處理的資料量大
面嚮應用，事務驅動	面向分析，分析驅動
面向操作人員，支援日常操作	面向決策人員，支援管理需要

 

 

 

弄清楚你的業務類型——OLTP or OLAP