網(wǎng)站維護數(shù)據(jù)庫的架構需求有哪些？

發(fā)布：2018-06-21 11:30:12 瀏覽：3744

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

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

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

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

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

在一定范圍內的數(shù)據(jù)丟失是可以接受的。如果一臺服務器消失了一段時間，將會損失一小筆錢，但將會無顏面對管理機構。不管怎么說，我們還是強烈希望數(shù)據(jù)庫服務器是高可用的，要求一年的容機時間加起來不要超過一天。因為，5分鐘的宕機時間比損失5分鐘的數(shù)據(jù)要昂貴得多。

為了災難恢復的目的，我們要求數(shù)據(jù)庫在最壞情況下能夠恢復到昨天的數(shù)據(jù)，而在多數(shù)情況下，我們當然希望能夠恢復到剛才的數(shù)據(jù)，使損失的數(shù)據(jù)不多于幾秒鐘。希望通常情況下恢復過程不要超過一小時，而在最壞情況，如損失大量的數(shù)據(jù)或服務器，則希望恢復時間不多于一天。

團隊對數(shù)據(jù)庫只有一般的能力，我們的團隊實際上是RubyonRails的專家，所以高級的數(shù)據(jù)庫問題還是需要外部的幫助。系統(tǒng)管理團隊也非常優(yōu)秀，但同樣不太擅長數(shù)據(jù)庫。

記住這些，我們來看看如何滿足這些需求。

易于成功的事情

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

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

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

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