iT邦幫忙

DAY 3
0

分散式資料系統的兩個問題根源:partition 和 replication。

先談partition。當資料放不進一台機器,或是對資料的運算太過耗時,單台機器無法負荷時,就是考慮partition的時候。

partition就是把資料切割放到多台機器上,首先要考量的,就是要怎麼切資料。

資料有幾種常見的切法:

  • Round-Robin: 資料輪流進多台機器。好處是load balance,壞處是不適合有session或資料相依性(need join)的應用。變型是可以用thread pool,每個機器固定配幾個thread,這可以避免某個運算耗時過久,而檔到後面運算的問題。
  • Range: 事先定好每台機器的防守範圍,如key在1~1000到A機器。優點是簡單,只需要維護一些metadata。問題是彈性較差,且會有hotspot的問題 (大量資料數值都集中在某個範圍)。MongoDB在早期版本只支援這種切割方式。
  • Hash: 用Hash來決定資料要在哪台機器上。簡單的Hash像是取餘數,但取餘數在新增機器時會有資料遷移的問題,所以現在大家比較常用Consistent Hashing來避免這個問題。Hash可以很平均的分佈,且只需要非常少的metadata。但Hash規則不好掌握,比方說我們就很難透過自定Hash規則讓某幾筆資料一定要在一起。大部分的Data Store都是採用Consistent Hashing。
  • Manual: 手動建一個對照表,優點是想要怎麼分配都可以,缺點是要自己控制資料和負載的均衡,且會有大量metadata要維護。

除了切法之外,還要決定用哪個欄位當做切割的key。

資料切割是非常應用導向的問題,因為有一好沒兩好,某個切法可能能讓某種運算很有效率,但會害到其他種運算。

有一個tradeoff在讀寫之間,優化寫可能會害到讀。比方說Round-Robin可以平均寫入負載,但Range Query就要到所有機器上查詢。而如果用流水號的Range來切,有利於流水號的Range Query,但寫入會擠在同一台機器上。

另一個tradeoff在application之間,比方說一個用戶表格資料如果用地區來切割,那就有利於常帶地區條件的應用,因為這些應用可以只鎖定幾個partition進行查詢,而不用把query灑到所有機器上。

為什麼我們不要把query灑到所有機器上,這就下次再講好了。


上一篇
Day 2: 分散式系統的面向
下一篇
Day 4: 為什麼有有些時候不要把query灑到所有機器上平行處理?
系列文
分散式資料處理,以Stream Computing為例30

尚未有邦友留言

立即登入留言