弄清楚你的業(yè)務(wù)類型——OLTP or OLAP
時(shí)間：2009-06-01 23:06:00
來(lái)源：UltraLAB圖形工作站方案網(wǎng)站
人氣：5735
作者：admin
在Oracle數(shù)據(jù)庫(kù)系統(tǒng)中，很多人沒有弄清楚自己的業(yè)務(wù)類型到底是什么，就在開始盲目的尋求優(yōu)化方法，而往往是把OLAP的方法使用在OLTP上，或者是OLTP的方法使用在OLAP上。這樣的使用，有的時(shí)候，對(duì)性能沒有任何的提高，甚至是大大的影響了性能，得到適得其反的效果。所以，在優(yōu)化系統(tǒng)之前，弄清楚自己的業(yè)務(wù)類型。
OLTP，也叫聯(lián)機(jī)事務(wù)處理(Online Transaction Processing)，表示事務(wù)性非常高的系統(tǒng)，一般都是高可用的在線系統(tǒng)，以小的事務(wù)以及小的查詢?yōu)橹?，評(píng)估其系統(tǒng)的時(shí)候，一般看其每秒執(zhí)行的transaction以及execute sql的數(shù)量。在這樣的系統(tǒng)中，每秒處理的transaction往往超過(guò)幾百個(gè)，或者是幾千個(gè)，select 語(yǔ)句的執(zhí)行量每秒幾千甚至幾萬(wàn)個(gè)。典型的OLTP系統(tǒng)如電子商務(wù)系統(tǒng)，銀行，證卷等等，如美國(guó)ebay的業(yè)務(wù)數(shù)據(jù)庫(kù)，就是很典型的OLTP數(shù)據(jù)庫(kù)。
OLTP系統(tǒng)最容易出現(xiàn)的瓶頸就是CPU與磁盤子系統(tǒng)。cpu則取決于邏輯讀以及內(nèi)部調(diào)用，如函數(shù)等等。一個(gè)執(zhí)行頻繁的SQL語(yǔ)句，如果每個(gè)語(yǔ)句可以減少很少的邏輯讀，也相當(dāng)于優(yōu)化了一些邏輯讀很差的大型語(yǔ)句。很多人不感覺不到這里的作用，覺得一個(gè)語(yǔ)句幾十個(gè)邏輯讀，執(zhí)行時(shí)間基本為0，就不需要優(yōu)化了，其實(shí)，只要他的執(zhí)行次數(shù)非常頻繁，而且有優(yōu)化的余地，就一定要優(yōu)化，如減少一定的邏輯讀或者降低執(zhí)行次數(shù)，都是優(yōu)化方法。
另外，一些計(jì)算性的函數(shù)，如sum，count，decode被非常頻繁的使用，也是非常消耗cpu的，我遇到一個(gè)系統(tǒng)，因?yàn)橐粋€(gè)sql語(yǔ)句，大量的使用了sum與decode進(jìn)行行列轉(zhuǎn)換，結(jié)果這一個(gè)語(yǔ)句就耗費(fèi)了整個(gè)機(jī)器一半以上的CPU。
那么，在一般的OLTP系統(tǒng)中，如果不考慮我上面說(shuō)的函數(shù)問題，那么，邏輯讀乘以執(zhí)行次數(shù)，決定了cpu的消耗程度，如一個(gè)語(yǔ)句，每秒執(zhí)行次數(shù)為500次，每個(gè)邏輯讀為15，但是，通過(guò)優(yōu)化，能讓每個(gè)語(yǔ)句的邏輯讀從15降到10，那么，每秒的邏輯讀就可以減少500*5=2500個(gè)，其實(shí)就是相當(dāng)于優(yōu)化了一個(gè)執(zhí)行頻率為每秒1次，每次邏輯讀為2500個(gè)的語(yǔ)句（注意，2500個(gè)邏輯讀，在oltp系統(tǒng)是非常差的語(yǔ)句）。再如，假定一個(gè)1GHZ的cpu每秒能正常處理的邏輯讀是100,000個(gè)，如果是10個(gè)邏輯讀一個(gè)的語(yǔ)句，每秒可以處理10,000個(gè)，而1000個(gè)邏輯讀一個(gè)的語(yǔ)句，每秒則只能處理100個(gè)。
同以上道理，物理讀乘以執(zhí)行次數(shù)，則決定了存儲(chǔ)子系統(tǒng)的處理能力，在一個(gè)OLTP環(huán)境中，物理讀一般都是db file sequential read決定的，也就是單塊讀，一個(gè)典型的OLTP系統(tǒng)，db file sequential read應(yīng)當(dāng)基本等于磁盤子系統(tǒng)的讀的IOPS。而磁盤子系統(tǒng)的IOPS處理能力，與cache命中率以及磁盤個(gè)數(shù)有很大的關(guān)系。我的一些文章中，也分析到了這些問題，如一個(gè)15K轉(zhuǎn)速的磁盤，每秒最多能處理的iops達(dá)到150個(gè)，基本就是極限了，如果cache不命中，那么100個(gè)磁盤，最多能處理的IOPS僅僅是15000個(gè)（但是，實(shí)際上，還基本達(dá)不到這個(gè)值）。
OLTP最常用的技術(shù)就是cache技術(shù)與btree索引，cache決定了很多語(yǔ)句不需要從磁盤子系統(tǒng)獲得數(shù)據(jù)，所以，web cache與oracle data buffer對(duì)OLTP系統(tǒng)是很重要的。另外，在索引使用方面，語(yǔ)句是越簡(jiǎn)單越好，這樣執(zhí)行計(jì)劃也穩(wěn)定，而且一定要使用綁定變量，減少語(yǔ)句解析，盡量減少關(guān)聯(lián)。其它方面，基本不使用分區(qū)技術(shù)，MV技術(shù)，并行技術(shù)以及位圖索引，因?yàn)椴l(fā)量很高，批量更新可能要盡量快速提交避免阻塞的發(fā)生。
在ebay的數(shù)據(jù)庫(kù)設(shè)計(jì)中，有一個(gè)很重要的點(diǎn)就是，數(shù)據(jù)庫(kù)只負(fù)責(zé)存放數(shù)據(jù)，業(yè)務(wù)邏輯盡量在業(yè)務(wù)層實(shí)現(xiàn)，因?yàn)閿?shù)據(jù)庫(kù)擴(kuò)展是困難的，而應(yīng)用服務(wù)器擴(kuò)展是簡(jiǎn)單的。其實(shí)，也就是說(shuō)，在高可用的OLTP環(huán)境中，數(shù)據(jù)庫(kù)使用越簡(jiǎn)單的功能越好。
OLAP，也叫聯(lián)機(jī)分析(Online Analytical Processing)，有的時(shí)候也叫DSS決策支持系統(tǒng)，就是我們說(shuō)的數(shù)據(jù)倉(cāng)庫(kù)。在這樣的系統(tǒng)中，語(yǔ)句的執(zhí)行量不是考核標(biāo)準(zhǔn)，因?yàn)橐粋€(gè)語(yǔ)句的執(zhí)行時(shí)間可能會(huì)非常長(zhǎng)，讀取的數(shù)據(jù)也非常多。所以，這樣的系統(tǒng)中，考核的標(biāo)準(zhǔn)往往決定于磁盤子系統(tǒng)的吞吐量。 #p#page_title#e#
磁盤子系統(tǒng)的吞吐量則直接取決于磁盤的個(gè)數(shù)，這個(gè)時(shí)候，cache基本是沒有效果的，這個(gè)時(shí)候數(shù)據(jù)庫(kù)的讀寫基本上是db file scattered read與direct path read/write。在我前面的一些文章中描述過(guò)，如果一個(gè)15K的磁盤的IO量每秒13M，那么，100個(gè)磁盤，最多能提供的吞吐量則是1300M/s（實(shí)際上，也基本達(dá)不到這個(gè)值）。如果磁盤個(gè)數(shù)足夠的話，還需要考慮采用比較大的帶寬，如4GB的光纖接口。
在OLAP系統(tǒng)中，常使用的技術(shù)有分區(qū)技術(shù)，并行技術(shù)。如分區(qū)技術(shù)可以使得一些大表的掃描變得很快（只掃描單個(gè)分區(qū)），而且方便管理。另外，如果分區(qū)結(jié)合并行的話，也可以使得整個(gè)表的掃描也會(huì)變得很快。并行技術(shù)除了與分區(qū)技術(shù)結(jié)合外，在oracle 10g中，與rac結(jié)合實(shí)現(xiàn)多節(jié)點(diǎn)的同時(shí)掃描，效果也非常不錯(cuò)，把一個(gè)任務(wù)，如select的全表掃描，平均的分派到多個(gè)rac的節(jié)點(diǎn)上去。
在OLAP系統(tǒng)中，不需要使用綁定變量，因?yàn)檎麄€(gè)系統(tǒng)的執(zhí)行量很少，分析時(shí)間對(duì)于執(zhí)行時(shí)間來(lái)說(shuō)，可以忽略，而且避免出現(xiàn)錯(cuò)誤的執(zhí)行計(jì)劃。但是OLAP中可以大量使用位圖索引，物化視圖，對(duì)于大的事務(wù)，盡量的尋求速度上的優(yōu)化，沒有必要象OLTP需要快速提交，甚至要刻意減慢執(zhí)行的速度。
特別是在高可用的OLTP環(huán)境中，不要盲目的把OLAP的技術(shù)拿過(guò)來(lái)用，如分區(qū)技術(shù)，如果不是大范圍的使用了分區(qū)關(guān)鍵字作為where條件，而采用其它的字段作為where條件，那么，如果是本地索引，你將不得不掃描多個(gè)索引，而性能變的更為低下。如果是全局索引，那分區(qū)的意義又何在，只是多出一份分區(qū)技術(shù)的license而已。
并行技術(shù)也是如此，一般是在大型任務(wù)的時(shí)候才使用，好比說(shuō)，實(shí)際生活中，一個(gè)比較大型的工作，如翻譯一本書，你可以先安排多個(gè)人，每個(gè)人翻譯不同的章節(jié)，這樣是可以提高翻譯速度，但是，你現(xiàn)在只是翻譯一頁(yè)，你也去分配不同的人翻譯不同的行，再組合起來(lái)，這個(gè)時(shí)間，你一個(gè)人或者早就翻譯完了。
位圖索引在我前幾篇文章中有交代，如果用在oltp環(huán)境中，可能因?yàn)樽枞秶?，很容易阻塞與死鎖，但是，在olap環(huán)境中，可能會(huì)因?yàn)槠涮赜械奶匦?，提高olap的查詢速度。mv也是基本一樣，包括觸發(fā)器等等，在dml頻繁的oltp系統(tǒng)上，很容易成為瓶頸，而在olap環(huán)境上，則可能會(huì)因?yàn)槭褂们‘?dāng)而提高查詢速度。
更多的差別與技術(shù)，細(xì)說(shuō)下來(lái)太多了，有些東西，是要靠大家慢慢去體會(huì)的，我這里也就不多說(shuō)了，大家可以平常在自己的業(yè)務(wù)中多多體會(huì)。
OLTP，也叫聯(lián)機(jī)事務(wù)處理(Online Transaction Processing)，表示事務(wù)性非常高的系統(tǒng)，一般都是高可用的在線系統(tǒng)，以小的事務(wù)以及小的查詢?yōu)橹?，評(píng)估其系統(tǒng)的時(shí)候，一般看其每秒執(zhí)行的transaction以及execute sql的數(shù)量。在這樣的系統(tǒng)中，每秒處理的transaction往往超過(guò)幾百個(gè)，或者是幾千個(gè)，select 語(yǔ)句的執(zhí)行量每秒幾千甚至幾萬(wàn)個(gè)。典型的OLTP系統(tǒng)如電子商務(wù)系統(tǒng)，銀行，證卷等等，如美國(guó)ebay的業(yè)務(wù)數(shù)據(jù)庫(kù)，就是很典型的OLTP數(shù)據(jù)庫(kù)。
OLTP系統(tǒng)最容易出現(xiàn)的瓶頸就是CPU與磁盤子系統(tǒng)。cpu則取決于邏輯讀以及內(nèi)部調(diào)用，如函數(shù)等等。一個(gè)執(zhí)行頻繁的SQL語(yǔ)句，如果每個(gè)語(yǔ)句可以減少很少的邏輯讀，也相當(dāng)于優(yōu)化了一些邏輯讀很差的大型語(yǔ)句。很多人不感覺不到這里的作用，覺得一個(gè)語(yǔ)句幾十個(gè)邏輯讀，執(zhí)行時(shí)間基本為0，就不需要優(yōu)化了，其實(shí)，只要他的執(zhí)行次數(shù)非常頻繁，而且有優(yōu)化的余地，就一定要優(yōu)化，如減少一定的邏輯讀或者降低執(zhí)行次數(shù)，都是優(yōu)化方法。
另外，一些計(jì)算性的函數(shù)，如sum，count，decode被非常頻繁的使用，也是非常消耗cpu的，我遇到一個(gè)系統(tǒng)，因?yàn)橐粋€(gè)sql語(yǔ)句，大量的使用了sum與decode進(jìn)行行列轉(zhuǎn)換，結(jié)果這一個(gè)語(yǔ)句就耗費(fèi)了整個(gè)機(jī)器一半以上的CPU。
那么，在一般的OLTP系統(tǒng)中，如果不考慮我上面說(shuō)的函數(shù)問題，那么，邏輯讀乘以執(zhí)行次數(shù)，決定了cpu的消耗程度，如一個(gè)語(yǔ)句，每秒執(zhí)行次數(shù)為500次，每個(gè)邏輯讀為15，但是，通過(guò)優(yōu)化，能讓每個(gè)語(yǔ)句的邏輯讀從15降到10，那么，每秒的邏輯讀就可以減少500*5=2500個(gè)，其實(shí)就是相當(dāng)于優(yōu)化了一個(gè)執(zhí)行頻率為每秒1次，每次邏輯讀為2500個(gè)的語(yǔ)句（注意，2500個(gè)邏輯讀，在oltp系統(tǒng)是非常差的語(yǔ)句）。再如，假定一個(gè)1GHZ的cpu每秒能正常處理的邏輯讀是100,000個(gè)，如果是10個(gè)邏輯讀一個(gè)的語(yǔ)句，每秒可以處理10,000個(gè)，而1000個(gè)邏輯讀一個(gè)的語(yǔ)句，每秒則只能處理100個(gè)。
同以上道理，物理讀乘以執(zhí)行次數(shù)，則決定了存儲(chǔ)子系統(tǒng)的處理能力，在一個(gè)OLTP環(huán)境中，物理讀一般都是db file sequential read決定的，也就是單塊讀，一個(gè)典型的OLTP系統(tǒng)，db file sequential read應(yīng)當(dāng)基本等于磁盤子系統(tǒng)的讀的IOPS。而磁盤子系統(tǒng)的IOPS處理能力，與cache命中率以及磁盤個(gè)數(shù)有很大的關(guān)系。我的一些文章中，也分析到了這些問題，如一個(gè)15K轉(zhuǎn)速的磁盤，每秒最多能處理的iops達(dá)到150個(gè)，基本就是極限了，如果cache不命中，那么100個(gè)磁盤，最多能處理的IOPS僅僅是15000個(gè)（但是，實(shí)際上，還基本達(dá)不到這個(gè)值）。
OLTP最常用的技術(shù)就是cache技術(shù)與btree索引，cache決定了很多語(yǔ)句不需要從磁盤子系統(tǒng)獲得數(shù)據(jù)，所以，web cache與oracle data buffer對(duì)OLTP系統(tǒng)是很重要的。另外，在索引使用方面，語(yǔ)句是越簡(jiǎn)單越好，這樣執(zhí)行計(jì)劃也穩(wěn)定，而且一定要使用綁定變量，減少語(yǔ)句解析，盡量減少關(guān)聯(lián)。其它方面，基本不使用分區(qū)技術(shù)，MV技術(shù)，并行技術(shù)以及位圖索引，因?yàn)椴l(fā)量很高，批量更新可能要盡量快速提交避免阻塞的發(fā)生。
在ebay的數(shù)據(jù)庫(kù)設(shè)計(jì)中，有一個(gè)很重要的點(diǎn)就是，數(shù)據(jù)庫(kù)只負(fù)責(zé)存放數(shù)據(jù)，業(yè)務(wù)邏輯盡量在業(yè)務(wù)層實(shí)現(xiàn)，因?yàn)閿?shù)據(jù)庫(kù)擴(kuò)展是困難的，而應(yīng)用服務(wù)器擴(kuò)展是簡(jiǎn)單的。其實(shí)，也就是說(shuō)，在高可用的OLTP環(huán)境中，數(shù)據(jù)庫(kù)使用越簡(jiǎn)單的功能越好。
OLAP，也叫聯(lián)機(jī)分析(Online Analytical Processing)，有的時(shí)候也叫DSS決策支持系統(tǒng)，就是我們說(shuō)的數(shù)據(jù)倉(cāng)庫(kù)。在這樣的系統(tǒng)中，語(yǔ)句的執(zhí)行量不是考核標(biāo)準(zhǔn)，因?yàn)橐粋€(gè)語(yǔ)句的執(zhí)行時(shí)間可能會(huì)非常長(zhǎng)，讀取的數(shù)據(jù)也非常多。所以，這樣的系統(tǒng)中，考核的標(biāo)準(zhǔn)往往決定于磁盤子系統(tǒng)的吞吐量。 #p#page_title#e#
磁盤子系統(tǒng)的吞吐量則直接取決于磁盤的個(gè)數(shù)，這個(gè)時(shí)候，cache基本是沒有效果的，這個(gè)時(shí)候數(shù)據(jù)庫(kù)的讀寫基本上是db file scattered read與direct path read/write。在我前面的一些文章中描述過(guò)，如果一個(gè)15K的磁盤的IO量每秒13M，那么，100個(gè)磁盤，最多能提供的吞吐量則是1300M/s（實(shí)際上，也基本達(dá)不到這個(gè)值）。如果磁盤個(gè)數(shù)足夠的話，還需要考慮采用比較大的帶寬，如4GB的光纖接口。
在OLAP系統(tǒng)中，常使用的技術(shù)有分區(qū)技術(shù)，并行技術(shù)。如分區(qū)技術(shù)可以使得一些大表的掃描變得很快（只掃描單個(gè)分區(qū)），而且方便管理。另外，如果分區(qū)結(jié)合并行的話，也可以使得整個(gè)表的掃描也會(huì)變得很快。并行技術(shù)除了與分區(qū)技術(shù)結(jié)合外，在oracle 10g中，與rac結(jié)合實(shí)現(xiàn)多節(jié)點(diǎn)的同時(shí)掃描，效果也非常不錯(cuò)，把一個(gè)任務(wù)，如select的全表掃描，平均的分派到多個(gè)rac的節(jié)點(diǎn)上去。
在OLAP系統(tǒng)中，不需要使用綁定變量，因?yàn)檎麄€(gè)系統(tǒng)的執(zhí)行量很少，分析時(shí)間對(duì)于執(zhí)行時(shí)間來(lái)說(shuō)，可以忽略，而且避免出現(xiàn)錯(cuò)誤的執(zhí)行計(jì)劃。但是OLAP中可以大量使用位圖索引，物化視圖，對(duì)于大的事務(wù)，盡量的尋求速度上的優(yōu)化，沒有必要象OLTP需要快速提交，甚至要刻意減慢執(zhí)行的速度。
特別是在高可用的OLTP環(huán)境中，不要盲目的把OLAP的技術(shù)拿過(guò)來(lái)用，如分區(qū)技術(shù)，如果不是大范圍的使用了分區(qū)關(guān)鍵字作為where條件，而采用其它的字段作為where條件，那么，如果是本地索引，你將不得不掃描多個(gè)索引，而性能變的更為低下。如果是全局索引，那分區(qū)的意義又何在，只是多出一份分區(qū)技術(shù)的license而已。
并行技術(shù)也是如此，一般是在大型任務(wù)的時(shí)候才使用，好比說(shuō)，實(shí)際生活中，一個(gè)比較大型的工作，如翻譯一本書，你可以先安排多個(gè)人，每個(gè)人翻譯不同的章節(jié)，這樣是可以提高翻譯速度，但是，你現(xiàn)在只是翻譯一頁(yè)，你也去分配不同的人翻譯不同的行，再組合起來(lái)，這個(gè)時(shí)間，你一個(gè)人或者早就翻譯完了。
位圖索引在我前幾篇文章中有交代，如果用在oltp環(huán)境中，可能因?yàn)樽枞秶?，很容易阻塞與死鎖，但是，在olap環(huán)境中，可能會(huì)因?yàn)槠涮赜械奶匦?，提高olap的查詢速度。mv也是基本一樣，包括觸發(fā)器等等，在dml頻繁的oltp系統(tǒng)上，很容易成為瓶頸，而在olap環(huán)境上，則可能會(huì)因?yàn)槭褂们‘?dāng)而提高查詢速度。
更多的差別與技術(shù)，細(xì)說(shuō)下來(lái)太多了，有些東西，是要靠大家慢慢去體會(huì)的，我這里也就不多說(shuō)了，大家可以平常在自己的業(yè)務(wù)中多多體會(huì)。
