多數Web數據庫都有人們稱(chēng)之為“高度事務(wù)型”的工作負荷，你也可能聽(tīng)說(shuō)過(guò)這稱(chēng)為OLTP(在線(xiàn)事務(wù)處理)。這名字有點(diǎn)誤導，因為這通常并不意味著(zhù)正在運行金融事務(wù)，在SOL意義上甚至也不意味著(zhù)是數據庫事務(wù)。通常只是意味著(zhù)應用程序做一些混合著(zhù)讀寫(xiě)一些行或一些行集的工作而已。很多互聯(lián)網(wǎng)應用都匹配下面的模式。

● 應用程序讀得多，讀對寫(xiě)的比率范圍從讀五次寫(xiě)一次到讀十次寫(xiě)一次不等，甚至一路飆升到讀幾百次オ寫(xiě)一次。

● 一次讀一行和一次讀多行是混合出現的。
 
● 一般來(lái)說(shuō)，寫(xiě)每次只影響一行。



這就是很多人稱(chēng)之為的“事務(wù)型”負荷。這看起來(lái)很正常，但不要假設每個(gè)人的負荷都這樣。例如，分析負荷通常都是批量插入，很少或沒(méi)有更新，以及每次都涉及到整個(gè)表的大量讀。很多數據庫都設計為能很好地處理這種負荷，因為需要分析數據的業(yè)務(wù)往往都有海量的數據，而且在特別為數據分析做過(guò)優(yōu)化的專(zhuān)有數據庫上花了大筆的錢(qián)。

事務(wù)型負荷意味著(zhù)，除非應用程序設計得很精巧，否則無(wú)法只做讀取操作(這樣設計是個(gè)好主意，但這是一個(gè)不同的話(huà)題)。從運維的角度來(lái)說(shuō)，與一直在線(xiàn)的特點(diǎn)一樣，這種事務(wù)型負荷也縮小了你的選擇空間。

一個(gè)相關(guān)的方面是數據與查詢(xún)的簡(jiǎn)單性。因為基礎的數據模型通常都不復雜，所以多數Web應用都生成前述的事務(wù)型負荷。如果將典型Web應用的數據模型做上

一些處于中心位置的表通常少于10個(gè)。很多這種表都會(huì )存儲類(lèi)的數據，如用戶(hù)，這些數據通常都是以一次一行的方式存取的。

網(wǎng)站的流量很大程度上決定了數據庫的流量。用戶(hù)瀏覽網(wǎng)站，就會(huì )在用戶(hù)表中對該用戶(hù)的那行記錄進(jìn)行讀寫(xiě)。瀏覽網(wǎng)站一般都會(huì )導致應用程序讀取數據集或數據區域來(lái)填充頁(yè)面瀏覽也會(huì )潛在地顯示一些統計數據，如你社會(huì )網(wǎng)絡(luò )中的好友數，而要生成這些統計數據，就要做匯總或聚集查詢(xún)。所以，查詢(xún)通常會(huì )滿(mǎn)足下面的模式:

● 讀寫(xiě)用戶(hù)表，一次一行。

● 以區域或集合方式讀取用戶(hù)自己的數據。以區域或集合方式讀取其他用戶(hù)的數據。
 
● 從該用戶(hù)與其他用戶(hù)的關(guān)聯(lián)表中讀取區域行(ranges of rows)。對該用戶(hù)和其他用戶(hù)的數據進(jìn)行匯總與計數。

行的區域與集合通常是由某些條件將結果限制為前N個(gè)(topN)的SQL查詢(xún)，如最新記錄。這些結果常常是分頁(yè)的，所以查詢(xún)條件會(huì )是一個(gè)偏移量和一個(gè)記錄條數的組合。不同的網(wǎng)站建設數據庫會(huì )用不同的方式來(lái)做這樣的查詢(xún)，所以我就不展示具體的查詢(xún)例子了。