隨着一個網站的業務不斷擴展,數據不斷增長,數據庫的壓力也會愈來愈大,對數據庫或者SQL的基本優化可能達不到最終的效果,咱們能夠採用讀寫分離的策略來改變現狀。讀寫分離如今被大量應用於不少大型網站,這個技術也不足爲奇了。ebay就作得很是好。ebay用的是oracle,據說是用Quest Share Plex 來實現主從複製數據。mysql
讀寫分離簡單的說是把對數據庫讀和寫的操做分開對應不一樣的數據庫服務器,這樣能有效地減輕數據庫壓力,也能減輕io壓力。主數據庫提供寫操做,從數據庫提供讀操做,其實在不少系統中,主要是讀的操做。當主數據庫進行寫操做時,數據要同步到從的數據庫,這樣纔能有效保證數據庫完整性。Quest SharePlex就是比較牛的同步數據工具,據說比oracle自己的流複製還好,mysql也有本身的同步數據技術。mysql只要是經過二進制日誌來複制數據。經過日誌在從數據庫重複主數據庫的操做達到複製數據目的。這個複製比較好的就是經過異步方法,把數據同步到從數據庫。程序員
主數據庫同步到從數據庫後,從數據庫通常由多臺數據庫組成這樣才能達到減輕壓力的目的。讀的操做怎麼樣分配到從數據庫上?應該根據服務器的壓力把讀的操做分配到服務器,而不是簡單的隨機分配。mysql提供了MySQL-Proxy實現讀寫分離操做。不過MySQL-Proxy好像好久不更新了。oracle能夠經過F5有效分配讀從數據庫的壓力。算法
ebay的讀寫分離(網上找到就拿來用了)sql
mysql的讀寫分離
上面說的數據庫同步複製,都是在從同一種數據庫中,若是我要把oracle的數據同步到mysql中,其實要實現這種方案的理由很簡單,mysql免費,oracle太貴。好像Quest SharePlex也實現不了改功能吧。好像如今市面尚未這個工具吧。那樣應該怎麼實現數據同步?其實咱們能夠考慮本身開發一套同步數據組件,經過消息,實現異步複製數據。其實這個實現起來要考慮不少方面問題,高併發的問題,失敗記錄等。其實這種方法也能夠同步數據到memcache中。據說oracle的Stream也能實現,不過沒有試過。數據庫
---------------------華麗的分割線--------------------------------------------------------------服務器
垂直分庫、水平分表架構
數據庫的水平劃分和垂直劃分很早之前就接觸了,只是沒有實踐,沒有什麼體會,只有最近兩年纔有接觸,今天也和你們聊聊。併發
垂直劃分 oracle
按照功能劃分,把數據分別放到不一樣的數據庫和服務器。異步
當一個網站開始剛剛建立時,可能只是考慮一天只有幾十或者幾百我的訪問,數據庫可能就個db,全部表都放一塊兒,一臺普通的服務器可能就夠了,並且開發人員也很是高興,並且信心十足,由於全部的表都在一個庫中,這樣查詢語句就能夠隨便關聯了,多美的一件事情。可是隨着訪問壓力的增長,讀寫操做不斷增長,數據庫的壓力絕對愈來愈大,可能接近極限,這時可能人們想到增長從服務器,作什麼集羣之類的,但是問題又來了,數據量也快速增加。
這時能夠考慮對讀寫操做進行分離,按照業務把不一樣的數據放到不一樣的庫中。其實在一個大型並且臃腫的數據庫中表和表之間的數據不少是沒有關係的,或者更加不須要(join)操做,理論上就應該把他們分別放到不一樣的服務器。例如用戶的收藏夾的數據和博客的數據庫就能夠放到兩個獨立的服務器。這個就叫垂直劃分(其實叫什麼不重要)。
當博客或者收藏夾的數據不斷增長後,應該怎麼辦,這樣就引出了另一個作法,叫水平劃分。
水平劃分
則把一個表的數據劃分到不一樣的數據庫,兩個數據庫的表結構同樣。怎麼劃分,應該根據必定的規則,能夠根據數據的產生者來作引導,上面的數據是由人產生的,能夠根據人的id來劃分數據庫。而後再根據必定的規則,先獲知數據在哪一個數據庫。
其實不少大型網站都經歷了數據庫垂直劃分和水平的劃分的階段。其實這個能夠根據經驗來肯定,不必定由某些硬性的規則。
以剛纔的博客爲例,數據能夠根據userid的奇偶來肯定數據的劃分。把id爲基數的放到A庫,爲偶數的放B庫。
這樣經過userId就能夠知道用戶的博客的數據在哪一個數據庫。其實能夠根據userId%10來處理。還能夠根據著名的HASH算法來處理。
當初看手機之家的架構是發現他們是:
水平切分:對數據進行水平分割。
a.最好分到同一個數據庫。
b.一種已經證實是切實可行的方案:主表+輔表。
c.有3種類型:主表不打散、主表打散無輔表、主表打散有輔表。
d.但對程序員來講,TA看到的只是一張表,不妨稱之爲虛表(邏輯表)? ,這張虛表實際上多是由N張實表(物理表)組成的。
哈哈,我仍是喜歡把數據分到不一樣的數據庫,這個能夠按照業務來和環境來定吧。
在說句題外話,若是是大型數據庫,還能夠作讀寫分離等。