弄清楚你的業務型別——oltp or olap2009-06-06 20:55 在oracle資料庫系統中，很多人沒有弄清楚自己的業務型別到底是什麼，就在開始盲目的尋求優化方法，而往往是把olap的方法使用在oltp上，或者是oltp的方法使用在olap上。這樣的使用，有的時候，對效能沒有任何的提高，甚至是大大的影響了效能，得到適得其反的效果。所以，在優化系統之前，弄清楚自己的業務型別。
1、什麼是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 on line transaction processing 主要是執行基本的 日常的事務處理，比如資料庫記錄的增 刪 改 查。比如在銀行訪問一筆款，就是乙個事務交易。oltp的特點一般有 1.實時性要求高 2.資料量不是很大 3.交易一般是確定的，所以oltp是對確定性的資料...
OLTP和OLAP的區別
聯機事務處理oltp on line transaction processing 主要是執行基本的 日常的事務處理，比如資料庫記錄的增 刪 改 查。比如在銀行訪問一筆款，就是乙個事務交易。oltp的特點一般有 1.實時性要求高 2.資料量不是很大 3.交易一般是確定的，所以oltp是對確定性的資料...
OLTP和OLAP的區別
聯機事務處理oltp on line transaction processing 主要是執行基本的 日常的事務處理，比如資料庫記錄的增 刪 改 查。比如在銀行訪問一筆款，就是乙個事務交易。oltp的特點一般有 1.實時性要求高 2.資料量不是很大 3.交易一般是確定的，所以oltp是對確定性的資料...