數據庫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方案結合使用。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章