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