將想法與焦點和您一起共享

網站維護數據庫的架構需求有哪些?發布者:本站     時間:2019-11-01 14:11:38

同往常一樣,你最好定義你的需求,特別是,把那些超出你的范圍從而成為別人的問題的內容寫成文檔。如果這一步搞清楚了,你就幫了每個人的大忙。你對詳誰應該解決問題決定得越快,則那個人為解決問題而做的預算和計劃也就越快。所以,讓我們例建一個假想的Web應用作為示例,非正式地把需求列出來。

我們虛構的應用將是每天24小時一直在線。在流量上將會有浪涌和波峰,隨著美國的東西海岸起床時間不同,每天會有兩次波峰。而且我們的波峰足夠高,從而能夠在平緩期進行維護操作,但不能停機,只能減少容量來做這些維護操作。停機會直接影響系統底線。將來,我們會擴展到歐洲和亞洲,從而停機就更不可行了。會有季節性的高流量,在某些流行網站的首頁也可能會提到我們,從而導致流量驟增。沒關系一一我們可以將功能降級,而不是垮掉。

數據庫的讀操作將占95%,而寫占5%。多數寫操作都是單行的,會有一些復雜查詢。這些查詢會非常耗時,為了提高效率,不得不把一些匯總預先計算出來,或對某些數據做非規范化處理,這將是一個非非常耗CPU的過程。我們將把這些耗時的分析工作的成本分推到整天,這樣一來,所用的數據會稍微有些過時。有日時候使用這些過時的數據是沒問題的,而有的時候,我們不得不在一天之內對數據進行逐步的增量更新。

數據庫模式的問題還沒有解決;應用還沒有成熟,正在快速開發中,包括數據庫模式也在不斷變化。結果就是必須進行在線部署。從而不得不在生產環境中運行 ALTER TABLE,作為更新數據庫模式的例行手段,而且還不能影響可用性。我們知道數據會越來越大,而ALTER花費的時間也會越來越長,以至于長到無法忍受。

持續增長的負載會超過單臺服務器的能力。能走多遠并不重要,因為只有三個數:零、1和多。無論如何,我們都不認為應用會增長到互聯網的規模,所以我們會考慮幾臺到幾十臺之間的情況。

在一定范圍內的數據丟失是可以接受的。如果一臺服務器消失了一段時間,將會損失一小筆錢,但將會無顏面對管理機構。不管怎么說,我們還是強烈希望數據庫服務器是高可用的,要求一年的容機時間加起來不要超過一天。因為,5分鐘的宕機時間比損失5分鐘的數據要昂貴得多。
 
為了災難恢復的目的,我們要求數據庫在最壞情況下能夠恢復到昨天的數據,而在多數情況下,我們當然希望能夠恢復到剛才的數據,使損失的數據不多于幾秒鐘。希望通常情況下恢復過程不要超過一小時,而在最壞情況,如損失大量的數據或服務器,則希望恢復時間不多于一天。

團隊對數據庫只有一般的能力,我們的團隊實際上是 Ruby on Rails的專家,所以高級的數據庫問題還是需要外部的幫助。系統管理團隊也非常優秀,但同樣不太擅長數據庫。

記住這些,我們來看看如何滿足這些需求。
 
易于成功的事情

開始研究特定的架構之前,我想指出一些需要計劃劃的事情,而不管最終的架構是什么:

● 要做的第一件事是增加緩存層。memcached非常好用,使用 memcached可以為數據庫減輕太多的負載,不用它簡直太蠢了。

● 不要讓用戶產生異常情況,如有10000個好友,或者1000張.照片。對于你認為成本昂貴的那些關鍵區域,要限制規模,不要允許無限制的增長,就可以將事情保持在合理的范圍內,而不會等到出現問題時,再向那些導致異常的人發火。防患于未然,就不會出現令人驚訝的事情,從而也就構成了良好的用戶體驗的一部分。

● 對待需求要小心,不要將自己的網站建設標準立得高于用戶的期望,不要為應用構建太昂貴的功能。顯示搜索結果的精確數量,以及精確的搜索結果頁面,就是一個經典的錯誤。Google不這樣做,所以你也不需要這樣做。



江苏快三开奖结果今天