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

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

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



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

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

一個相關的方面是數據與查詢的簡單性。因為基礎的數據模型通常都不復雜，所以多數Web應用都生成前述的事務型負荷。如果將典型Web應用的數據模型做上

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

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

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

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

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