在完成本系列的第1部分之后验烧，你的服務(wù)器現(xiàn)在可以水平擴展了，你已經(jīng)可以處理數(shù)千個并發(fā)請求了色瘩。但在這條路上的某個地方伪窖，您的應(yīng)用程序變得越來越慢，最終崩潰居兆。原因是:您的數(shù)據(jù)庫覆山。它是MySQL，不是嗎?
現(xiàn)在所需要的改變比添加更多的克隆服務(wù)器更為激進泥栖，甚至可能需要一些大膽的嘗試簇宽。最后，你可以從兩種路徑中選擇:
路徑#1是堅持使用MySQL吧享，讓“怪獸”繼續(xù)運行魏割。雇傭一個數(shù)據(jù)庫管理員(DBA)，告訴他做主從復(fù)制(從slave讀取钢颂，向master寫入)钞它，并通過添加RAM，更多RAM的來升級主服務(wù)器。在某些月份遭垛，您的DBA會想到“分片”尼桶、“非正規(guī)化”和“SQL調(diào)優(yōu)”這樣的詞，并會擔心接下來幾周的必要加班耻卡。在這一點上疯汁，每一個保持數(shù)據(jù)庫運行的新操作都將比前一個操作更昂貴和耗時。如果您在數(shù)據(jù)集仍然很小且易于遷移時選擇了Path #2卵酪，那么情況可能會更好。
路徑#2意味著從一開始就去正規(guī)化谤碳，在任何數(shù)據(jù)庫查詢中不再包含任何join溃卡。你可以繼續(xù)使用MySQL，并像使用NoSQL數(shù)據(jù)庫一樣使用它蜒简，或者你可以切換到更好瘸羡、更容易伸縮的NoSQL數(shù)據(jù)庫，如MongoDB或CouchDB搓茬。join現(xiàn)在需要在應(yīng)用程序代碼中完成犹赖。越早執(zhí)行這一步驟，將來需要更改的代碼就越少卷仑。但是峻村，即使你成功地切換到最新和最好的NoSQL數(shù)據(jù)庫，并讓你的應(yīng)用程序做數(shù)據(jù)集連接锡凝，很快你的數(shù)據(jù)庫請求將再次變得越來越慢粘昨。您需要引入一個緩存。
引用：
https://www.lecloud.net/post/7994751381/scalability-for-dummies-part-2-database
