關聯式資料庫集群

背景

當站點的規模不斷膨脹，這給資料庫帶來巨大的查詢壓力，單單資料庫效能優化已經是不夠的，需對資料庫進行伸縮擴充套件。有三種方式：

1、資料庫主從

2、資料表分庫（垂直分割槽）

3、資料分割槽（水平分割槽）

ps：事實上，很多大規模的站點基本上經歷了從簡單主從複製到垂直分割槽，再到水平分割槽的步驟。

資料庫主從

幾乎所有主流關聯式資料庫都支援資料複製功能，可將主伺服器資料複製到從伺服器，這個功能可以對資料庫進行簡單擴充套件。在主從基礎上，採用讀寫分離的方法將應用程式中對資料庫的寫操作指向主伺服器（保證資料一致性），而將讀操作指向從伺服器。

為何有用？

大多數站點的資料庫讀操作要比寫操作更密集，而且查詢條件相對複雜，資料庫能力大部分消耗在查詢上。通過將大量讀操作剝離出來，轉移到更多的從伺服器上實現水平擴充套件，是非常簡單有效的。

mysql為例

mysql主從配置簡單，只需做兩點：

1、開啟主伺服器上的二進位制日誌（log-bin）。

2、在主伺服器和從伺服器上分別進行簡單的配置和授權。

分發讀操作方式：

應用程式本身不擅長分散讀操作到多台從伺服器上，可使用資料庫反向**來分發。mysql可使用mysql proxy。

資料表分庫（垂直分割槽）

對於某些寫操作更加頻繁的站點，主從方式的主伺服器還是會成為瓶頸，從伺服器的擴充套件並沒帶來好的效益。這時可以根據業務分割，將不同業務資料表部署在不同的資料庫集群上，這就是資料表分庫，也叫垂直分割槽。

制約

這種方式有個制約，跨庫的表不能進行join操作，原本簡單聯合語句就能完成的，分庫後需要一步步查詢資訊。但是，分庫後的查詢方式會更加容易保持相對穩定的開銷。

例子，**的使用者和商品資訊，將這兩個資料表拆分成兩個資料庫。

資料分割槽（水平分割槽）

當資料表分庫後，某一業務資料庫（已經是很精細的業務）還是無法承受寫操作壓力時。這時可以考慮資料分割槽，將同一資料表中的資料通過特定演算法進行分離，分別儲存在不同資料表中，從而可以部署在不同的資料庫伺服器上。

例子，facebook的使用者表，可以根據user_id的奇偶性將使用者劃分為兩部分，分別儲存到不同資料庫伺服器上。

參考文獻

1、《構建高效能web站點》

2、《大型**技術架構》