MySql的基本架構演變

標籤：

【MySql的基本架構演變】

　　沒有並發的增長，也就沒有必要做高可擴充性的架構。

　　Scale-up :  縱向擴充，通過替換為更好的機器和資源來實現伸縮，提升服務能力
　　Scale-out : 橫向擴充,  通過加節點（機器）來實現伸縮，提升服務能力
　　對於互連網的高並發應用來說，無疑Scale out才是出路，通過縱向的買更高端的機器一直是我們所避諱的問題，也不是長久之計。

　　一個服務，當面臨更高的並發的時候，能夠通過簡單增加機器來提升服務支撐的並發度，且增加機器過程中對線上服務無影響(no down time)，這就是可擴充性的理想狀態！

【V1.0  簡單網站架構】

　　一個簡單的小型網站或者應用背後的架構可以非常簡單,  資料存放區只需要一個mysql instance就能滿足資料讀取和寫入需求（這裡忽略掉了資料備份的執行個體），處於這個時間段的網站，一般會把所有的資訊存到一個database instance裡面。

　　

　　在這樣的架構下，資料存放區的瓶頸是什麼？
　　1.資料量的總大小  一個機器放不下時
　　2.資料的索引（B+ Tree）一個機器的記憶體放不下時
　　3.訪問量(讀寫混合)一個執行個體不能承受

　　只有當以上3件事情任何一件或多件滿足時，我們才需要考慮往下一級演變。 從此我們可以看出，事實上對於很多小公司小應用，這種架構已經足夠滿足他們的需求了，初期資料量的準確評估是杜絕過度設計很重要的一環，畢竟沒有人願意為不可能發生的事情而浪費自己的經曆。

　　這裡簡單舉個例子，對於使用者資訊這類表 （3個索引），16G記憶體能放下大概2000W行資料的索引，簡單的讀和寫混合訪問量3000/s左右沒有問題。

【V2.0 垂直分割】

　　一般當V1.0 遇到瓶頸時，首先最簡便的拆分方法就是垂直分割，何謂垂直？就是從業務角度來看，將關聯性不強的資料拆分到不同的instance上，從而達到消除瓶頸的目標。以圖中的為例，將使用者資訊資料，和業務資料拆分到不同的三個執行個體上。對於重複讀類型比較多的情境，我們還可以加一層cache，來減少對DB的壓力。

　　

　　

　　在這樣的架構下，我們來看看資料存放區的瓶頸是什嗎？

　　1.單一實例單業務 依然存在V1.0所述瓶頸

　　遇到瓶頸時可以考慮往本文更高V版本升級, 若是讀請求導致達到效能瓶頸可以考慮往V3.0升級， 其他瓶頸考慮往V4.0升級

【V3.0  主從架構】

　此類架構主要解決V2.0架構下的讀問題，通過給Instance掛資料即時備份的思路來遷移讀取的壓力，在Mysql的情境下就是通過主從結構，主庫抗寫壓力，通過從庫來分擔讀壓力，對於寫少讀多的應用，V3.0主從架構完全能夠勝任

　　

　　在這樣的架構下，我們來看看資料存放區的瓶頸是什嗎？
　　1.寫入量主庫不能承受

【V4.0  水平分割】

　　對於V2.0 V3.0方案遇到瓶頸時，都可以通過水平分割來解決，水平分割和垂直分割有較大區別，垂直分割拆完的結果，在一個執行個體上是擁有全量資料的，而水平分割之後，任何執行個體都只有全量的1/n的資料，以Userinfo的拆分為例，將userinfo拆分為3個cluster，每個cluster持有總量的1/3資料，3個cluster資料的總和等於一份完整資料（註：這裡不再叫單個執行個體 而是叫一個cluster 代表包含主從的一個小mysql叢集）

　　　　　　

參考：http://www.cnblogs.com/Creator/p/3776110.html

MySql的基本架構演變