資料分佈背後的邏輯
在分散式資料庫及大資料平臺中，資料如何分佈到多臺機器中是個很關鍵的問題。因為很多運算是資料密集型的，如果資料分佈做得不好，就會導致網路傳輸量變大，從而影響效能。
一般來講，分散式資料庫會提供兩種分佈策略：對於大表按某個欄位（的HASH值）去分佈，大多數情況會使用主鍵，這樣可以把資料分拆到多臺機器上；對於小表則採用複製性分佈，也就是每個機器上都會複製一份。
但是，表的大小並沒有絕對的判定標準，很大很小的表都容易識別並採取相應的策略，而那些資料不多不少的中型資料表又該採取哪種策略呢？
要搞清這個問題，我們就要知道資料分佈背後的邏輯，什麼樣的資料分佈才算是好的？
合理的資料分佈能夠有效地減少JOIN運算過程中的網路傳輸量！這也是資料分佈的關鍵目標。
大部分常規運算都容易分拆到多個機器上分別執行後再彙總，這樣，原則上資料只要儘量平均分佈就可以由各節點來分攤計算負擔。但是JOIN不一樣，它涉及關聯計算，如果JOIN的兩條記錄不在同一個節點上，那就需要把它們先傳輸到一起才能進行運算，這種事當然越少越好了。
那麼怎樣才能儘量避免JOIN過程中的資料傳輸呢？
這又要回到我們已經討論過多次的JOIN型別。回顧一下去年的文章《ofollow,noindex">JOIN運算剖析 》，我們把JOIN分成三類：外來鍵、同維、主子。同維表和主子表的JOIN是在主鍵（或部分）之間進行的，主鍵不同的兩條記錄是不可能發生JOIN的，這樣，如果資料已經按主鍵分佈的，就不會發生跨節點JOIN的現象了。而外來鍵表的JOIN，維表記錄可能被事實表隨意引用，無論怎樣將維表分佈，都有可能發生跨節點JOIN的現象，只有將維表複製到每個節點上去，才能避免JOIN過程中的網路傳輸。
這樣，我們就知道了：同維表和主子表要按主鍵欄位去分佈，而維表則要採用複製性策略，每節點都放一份，這樣能有效減少跨節點JOIN運算。
但這和大表小表有什麼關係？
一般來講，記錄事件的事實表會隨著時間推移而不斷增大，常常是大表，而這種表之間的JOIN大多數是同維表或主子表（比如訂單及明細）關係。而用於外來鍵指向的維表主要是用於儲存一些不常變化的屬性資訊，相對要小一點。於是，本來是事實表要分拆分佈、維表要複製分佈的策略，就會表現成“大表”分拆、“小表”複製的特徵了。
明白了這一點，我們就不會再糾結大表小表的界限在哪裡了，其實沒有大小之分，而是在資料結構中的地位決定的。
不過，關係資料庫中並沒有明確的事實表和維表概念，需要我們主動地去識別，有意識地設定分佈方案。而且，一定要用主鍵去分佈，隨便找一個無關欄位去分佈，就起不到減少跨節點JOIN的作用了。
有些大資料平臺只提供自動（按大小）分佈的方案，不能強制複製維表，也不能讓同維表和主子表按主鍵同步分佈，這時候分散式計算的效果就不會好了，在選擇這些計算體系時需要特別注意。
原文釋出時間為：2018-10-9
本文作者：蔣步星