「分散式技術專題」資料切分與合併

Hubble資料庫發表於2023-02-14

為何進行資料切分

海量資料的儲存和訪問成為系統設計的瓶頸問題。每天海量資料的增長無疑對資料庫造成了相當高的負載。給系統的穩定性和擴充套件性造成了極大的問題。透過資料的拆來提高系統整體效能,擴充系統整體容量,橫向擴充套件資料層已經成為分散式資料庫架構師及開發人員首選的方式。因此,需要能資料庫的資料進分切分儲存。

為何進行資料合併

儲存檔案會被後臺的管理程式仔細地監控起來以確保它們處於控制之下。隨著 memstore的刷寫會生成很多磁碟檔案。會生成很小檔案,如果檔案的數目達到閾值,合併(compaction)過程將把它們合併成數量更少的體積更大的檔案,便於資料庫更好地進行資料維護的目的。

原理

資料的切分( Sharding)原理:依據其切分規則的型別,能夠分為兩種切分模式。一種是依照不同的表(或者Schema)來切分到不同的資料庫(主機)之上。這樣的切能夠稱之為資料的垂直(縱向)切分。第二種則是依據表中的資料的邏輯關係,將同一個表中的資料依照某種條件拆分到多臺資料庫(主機)上面,這樣的切分稱之為資料的水平(橫向)切分。
資料合併原理:
小合併,指選取一些小的、相鄰的 StoreFile將他們合併成一個更大的StoreFile,在這個過程中不會處理已經Deleted的檔案。一次Minor Compaction的結果是更少並且更大的StoreFile。
大合併,將所有的 StoreFile合併成一個StoreFile,這個過程會清理三種資料:被刪除的資料、TTL過期資料、版本號超過設定版本號的資料(VERSION)。

實現方式

切分 一個 Region代表一個表的一段資料集合,當Region太大,hubbleMaster會將其拆分。Region太大會導致讀取效率太低,遍歷時間太長,透過將大資料拆分到不同機器上,分別查詢再聚合。

Region可以手動和自動拆分

手動拆分

在建表的時候就定義好拆分點的演演算法,建立表,並傳入拆分點演演算法,就可以在建表同事定義拆分點演演算法。開始的時候定義預拆分,匯入初始資料,之後使用自動拆分來讓 Hubble資料庫自動管理Region。不要關閉自動拆分。避免因為直接使用預拆分導致的熱點Region問題。

自動拆分

固定大小拆分策略,如果單個 Region大小超過了閥值那麼就拆分為兩個Region,這種策略使得叢集的Region大小很平均。動態限制拆分策略,是新版本的預設策略。有的資料庫檔案增長是翻倍的資料量大小時,進行拆分,如64M、128M、256M等。
熱點拆分策略,這是唯一考慮到熱點資料的拆分策略,如果資料庫中的 Region某些短時間內被訪問很頻繁,承載了很大壓力,就是熱點Region。

合併

在進行合併的過程中,不同機器上的 Region需要進行合併,Region中的資料夾需要合併,資料夾中的sst檔案也需要合併,合併過程會進行大量的讀寫操作,極大程度上佔用資源;Region的合併稱之為大合併,一般情況下是關閉的,尤其是業務高峰期;平時只會進行sst檔案之間的小合併;只有在業務低峰期(節假日)進行Region之間的大合併。一般存放標籤性質的資料包表,當達到過期時間時需要進行Region之間的合併操作。

合併有兩種方式:

手動合併(又稱冷合併)

透過客戶端命令列的方式,透過人工指定所所需合併檔案,呼叫合併的工具類來實現兩個 Region的合併,但是有一個前提,必須保證這兩個Region已經下線,保證HubbleMaster和所有的HubbleRegionServer都停掉,否則會報錯,但是這樣太麻煩了,而且不適合生產使用。

自動合併(又秒熱合並)

在合併策略中配置檔案合併策略閥值,當系統檔案資料達到這值後,系統自動觸發合併任務。

優勢與劣勢

優勢

拆分規則明確。

系統之間進行整合或擴充套件很容易。

按照成本、應用的等級、應用的型別等將表放到不同的機器上便於管理。

切分的表結構相同,應用層改造較少,只需要增加路由規則即可。

提高了系統的穩定性和負載能力。

劣勢

提高了系統的複雜度。

事務處理複雜。

切分後,資料是分散的,跨庫 join操作難和效能差。

面臨挑戰

分片事務的一致性機制實現複雜。

分散式事務的問題。

資料遷移的時候麻煩。

 

以上為資料切分與合併, 「分散式技術專題」是國產資料庫 hubble 團隊精心整編,專題會持續更新,歡迎大家保持關注。


來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/70026685/viewspace-2935121/,如需轉載,請註明出處,否則將追究法律責任。

相關文章