● 應用程序讀得多,讀對寫的比率范圍從讀五次寫一次到讀十次寫一次不等,甚至一路飆升到讀幾百次オ寫一次。
● 一次讀一行和一次讀多行是混合出現(xiàn)的。
● 一般來說,寫每次只影響一行。
這就是很多人稱之為的“事務型”負荷。這看起來很正常,但不要假設每個人的負荷都這樣。例如,分析負荷通常都是批量插入,很少或沒有更新,以及每次都涉及到整個表的大量讀。很多數(shù)據(jù)庫都設計為能很好地處理這種負荷,因為需要分析數(shù)據(jù)的業(yè)務往往都有海量的數(shù)據(jù),而且在特別為數(shù)據(jù)分析做過優(yōu)化的專有數(shù)據(jù)庫上花了大筆的錢。
事務型負荷意味著,除非應用程序設計得很精巧,否則無法只做讀取操作(這樣設計是個好主意,但這是一個不同的話題)。從運維的角度來說,與一直在線的特點一樣,這種事務型負荷也縮小了你的選擇空間。
一個相關的方面是數(shù)據(jù)與查詢的簡單性。因為基礎的數(shù)據(jù)模型通常都不復雜,所以多數(shù)Web應用都生成前述的事務型負荷。如果將典型Web應用的數(shù)據(jù)模型做上
一些處于中心位置的表通常少于10個。很多這種表都會存儲類的數(shù)據(jù),如用戶,這些數(shù)據(jù)通常都是以一次一行的方式存取的。
網(wǎng)站的流量很大程度上決定了數(shù)據(jù)庫的流量。用戶瀏覽網(wǎng)站,就會在用戶表中對該用戶的那行記錄進行讀寫。瀏覽網(wǎng)站一般都會導致應用程序讀取數(shù)據(jù)集或數(shù)據(jù)區(qū)域來填充頁面瀏覽也會潛在地顯示一些統(tǒng)計數(shù)據(jù),如你社會網(wǎng)絡中的好友數(shù),而要生成這些統(tǒng)計數(shù)據(jù),就要做匯總或聚集查詢。所以,查詢通常會滿足下面的模式:
● 讀寫用戶表,一次一行。
● 以區(qū)域或集合方式讀取用戶自己的數(shù)據(jù)。以區(qū)域或集合方式讀取其他用戶的數(shù)據(jù)。
● 從該用戶與其他用戶的關聯(lián)表中讀取區(qū)域行(ranges of rows)。對該用戶和其他用戶的數(shù)據(jù)進行匯總與計數(shù)。
行的區(qū)域與集合通常是由某些條件將結果限制為前N個(topN)的SQL查詢,如最新記錄。這些結果常常是分頁的,所以查詢條件會是一個偏移量和一個記錄條數(shù)的組合。不同的網(wǎng)站建設數(shù)據(jù)庫會用不同的方式來做這樣的查詢,所以我就不展示具體的查詢例子了。
本文地址:http://m.123beaconmarketing.com//article/3315.html