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

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

● 一次讀一行和一次讀多行是混合出現(xiàn)的。
 
● 一般來說，寫每次只影響一行。



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

事務(wù)型負(fù)荷意味著，除非應(yīng)用程序設(shè)計得很精巧，否則無法只做讀取操作(這樣設(shè)計是個好主意，但這是一個不同的話題)。從運維的角度來說，與一直在線的特點一樣，這種事務(wù)型負(fù)荷也縮小了你的選擇空間。

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

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

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

● 讀寫用戶表，一次一行。

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

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