數據庫sharding（scale up to scale out）

sharding是將一個大數據庫按照必定規則拆分紅多個小數據庫的一門技術.

 

    當咱們的應用數據量愈來愈多，訪問量愈來愈大的時候，咱們會做何選擇？繼續提高數據庫服務器的性能仍是採用一項技術讓數據庫平滑擴展？雖然伴隨着服務器的更新換代，性能愈來愈好，更換更加豪華的服務器能暫時解決這個問題，可是不管是從花費和可控都沒法讓人滿意。這時數據庫sharding是一個更加可行的方案。

 

    經常使用的sharding方案有如下幾種，

 

    1。按功能劃分（垂直切分）

 

        將不一樣功能相關的表放到不一樣的數據庫中，譬如將用戶管理相關表放到shard 1上，將blog相關表放到shard 2上。。。這樣作的好處是很是直觀，當須要用戶列表時，我就到shard 1上獲取。。。。這樣也有一個問題，當某一部分的功能其數據量或性能要求超出了可控的範圍，咱們就須要繼續對其進行深刻的sharding。

 

    2。按表中某一字段值的範圍劃分（水平切分）

 

        當伴隨着某一個表的數據量愈來愈大，以致於不能承受的時候，就須要對她進行進一步的切分。一種選擇是根據key的範圍來作切分，譬如userID爲1-10000的放到shard 10上，userID爲10000到20000的放到shanrd 11上。。。這樣的擴展就是可預見的。另外一種是根據某一字段值得來劃分，譬如根據用戶名的首字母，若是是a-d，就屬於shard 20，e-h就屬於shard 21。。。這樣作也存在不均衡性，當某個範圍超出了shard所能承受的範圍就須要繼續切分。還有按日期切分等等，

 

    3。基於hash的切分

 

        相似於memcached的key hash算法，一開始肯定切分數據庫的個數，經過hash取模來決定使用哪臺shard。這種方法可以平均的來分配數據，可是伴隨着數據量的增大，須要進行擴展的時候，這種方式沒法作到在線擴容。每增長節點的時候，就須要對hash算法從新運算，數據須要從新割接。

 

    4。基於路由表的切分

 

         前面的幾種方式都是跟據應用的數據來決定操做的shard，基於路由表的切分是一種更加鬆散的方法。它單獨維護一張路由表，根據用戶的某一屬性來查找路由表決定使用哪一個shard，這種方式是一種更加通用的方案。譬如咱們在系統中維護一張表-（用戶所屬省-〉shard），這樣每一個用戶咱們知道是哪一個省的，去路由表查找，就知道它所在的shard。由於每次數據操做的時候都須要進行路由的查找，因此將這些內容存儲到一臺獨立cache上是一個很是好的方式，譬如memcached。這種切分的方式同時也帶來了另外一個好處，當須要增長shard的時候，能夠在不影響在線應用的狀況下來執行，固然這也跟應用程序的架構設計相關，你的設計必須適用這種增長。

 

 

    雖然應用sharding會帶來顯而易見的好處，可是它也有一些固有的問題須要咱們瞭解，這些問題大體分紅如下幾類，

 

    1。shard的擴容

 

        噹噹前的shard已經不能適用當前的應用需求時，就須要對shard數據庫進行擴容，增長shard意味着須要對原有的shard數據進行遷移，這個過程是很是複雜，並且可能會致使數據的不一致（一邊寫、一邊遷移）或者其餘應用問題，所以擴容通常選擇在凌晨等時間進行。

 

    2。聯合多個shard的表數據查詢

 

        這個是shard固有的問題，當遇到這樣的問題時，你須要獲取各個shard的數據，而後對這些數據進行彙總，不少時候由於如今的網絡速度比較發達這個問題能夠幾乎被忽略掉。可是若是要進行數據的分析或挖掘，shard就會存在問題，一般面對這種對於數據要求不是那麼實時的狀況下，能夠採用將shard數據同步到彙總數據庫的方案，olap能夠在這臺彙總數據庫上進行，這就須要在每臺shard上進行數據的定時同步，這增長了程序的複雜性；若是要求實時的狀況下，採用sharding方案會是一個毀滅性打擊。

 

    3。其餘

 

        咱們如今作的系統就是採用的按照路由表切分的sharding方案，並且咱們須要要求不是那麼實時的彙總數據以提供數據的分析和挖掘，同時咱們的基礎數據都是在彙總數據庫中進行管理，經過oracle的高級複製到shard節點上。在shard數據庫向彙總數據庫同步數據的時候，咱們是經過oracle數據庫的存儲過程實現的，這種架構方式致使了數據庫很是的複雜，同時還存在了一些其餘問題，譬如同步會平白無故的斷掉。。。這就須要採用一些其餘手段來維持數據的延遲一致性。

 

    咱們的sharding還在改進，咱們的shard還在增長，咱們還須要不斷努力使咱們的應用更加高效。

 

    有時候以爲咱們的社會就像一個巨大的多層sharding方案，中央、省（自治區）、市。。。

 

-------------------------------------------------------------

還有一種數據庫方案是master-slave，一臺master主要負責數據的更新，而後經過高級複製等手段將數據複製到各個slave節點，slave節點負責查詢。這種結構是無論master和slave都擁有所有的數據，master到slave的數據存在必定的延遲。能夠跟sharding方案結合使用。