Greenplum
如何實現事實和維度之間的局部連接？
事實表通常包含一個複合主鍵，該主鍵由定義其粒度的所有維度的鍵組成。如果我們通過這個鍵分配表，它不可能完成到它所綁定的任何維度的本地連接，因為這些表是由它們自己的 PK 分佈的，這與為事實生成的散列不匹配。
我猜如果維度很小，它不會有太大關係，但如果維度很大，例如具有數百萬個 CUSIP 和其他標識符的安全主表，如何實現本地連接？
為事實選擇分佈鍵的標準方法是什麼？
您的複合主鍵分佈方法將創建一個低偏斜或無偏斜的分佈。這很好，但正如您所指出的，它會在其他領域帶來一些成本。在實踐中，均勻分佈通常是次要問題。分佈往往是通過最大的常用連接或最常見的聚合。在您描述的情況下，這聽起來是安全描述符維度。
MPP 數據庫中的數據分佈旨在優化兩個指標：最小化數據移動和利用集群中所有可用的硬體性能。通過為大型連接和聚合操作共同定位數據來最小化數據移動。使用所有硬體來獲得查詢的最佳性能要求數據均勻分佈**，**並且典型的查詢不會在單個節點上處理數據。因此，當選擇一個分佈鍵來最小化數據運動分佈時，不僅要盡量減少偏斜，而且還要避免按查詢謂詞中常用的欄位進行分佈。
如果安全維度最大，則按安全維度鍵分配事實表。由於它很大，它本身應該有足夠的熵來防止歪斜。
另一方面，您不希望這樣做的一種情況是，如果您經常使用 WHERE 子句中的安全維度進行選擇，並檢索或處理大量事實。這會將所有處理載入到一個節點上。如果有一個足夠大的維度鍵、具有另一個維度的複合鍵，或者僅使用隨機分佈，這將導致您使用另一個維度鍵。
另一方面，如果您經常進行大量此類查詢，那麼在節點上傾斜工作負載可能不是問題，因為它們都忙於對自己的查詢進行本地連接 - 使用分佈鍵作為表單的負載均衡。我看過這個建議，但我自己不太喜歡。