Amazon Redshift - 複製 - 數據加載與查詢性能問題

我們正在將我們的數據倉庫從Oracle遷移到Redshift。目前，我們有兩個Oracle數據庫實例 - 一個DW實例（主要）從一天中的不同來源加載數據，另一個DW（輔助）實例從主DW複製數據。所有報告平臺都指向輔助DW實例。我們如何在Redshift中解決這個問題？我們是否需要從另一個複製兩個Redshift實例？如果我們只有一個Redshift實例，則數據加載開銷會影響查詢性能。會有桌子鎖問題嗎？Amazon Redshift - 複製 - 數據加載與查詢性能問題

感謝您的建議。謝謝。

來源

2017-03-15 Suri

這實際上取決於您的報表平臺需要多快才能訪問全天加載的數據。如果可以等待，那麼在安靜的時間進行批量加載是有意義的。我懷疑你在當前的設置中使用複製，你需要儘快加載和使用數據。

在這種情況下，使用Redshift的工作負載管理（WLM）設置是有意義的。這允許您指定多個工作負載組，併爲每個分配一個併發級別和羣集資源分配。使用此模型，您可以對資源進行限制，以確保爲報表工具和最終用戶查詢性能提供了一致的資源分配，同時仍將部分集羣的查詢隊列和資源專用於數據加載。

這也可以避免使用兩個單獨的數據庫實例來處理加載和提供數據的需要。

在這裏看到的WLM更詳細的紅移：http://docs.aws.amazon.com/redshift/latest/dg/cm-c-implementing-workload-management.html

來源

2017-06-18 21:44:40 GShenanigan

永遠不要閱讀，並從同一個實例寫。甚至在Redshift中也沒有。即使在一般情況下，任何迫使您從同一臺機器上讀寫的系統都反映了糟糕的設計。

既然您正在討論有關Amazon Redshift的問題，我可以非常輕鬆地認爲您擁有分析數據。（Redshift有一個列式體系結構針對讀取進行了優化，而不是寫入，因此如果您碰巧在Redshift上存儲事務數據，我會建議您重新考慮您的決定）。

設計有關我們談論的分析數據任何下文之前，我們應該始終認爲：

這將是龐大的。
它將在不久的將來進一步擴大規模。

當您縮放時，從同一臺機器讀取和寫入將是災難性的。不要忘記鎖。刪除/截斷將在表上保存Exclusive Locks。如果碰巧其他一些進程用戶已經獲得了這個鎖，那麼即使在該表上寫入也會失敗，從而搞亂了數據。

上述原因可能足以讓人信服爲什麼不是使用單個倉庫來讀取/寫入數據。

按照下面的模式，這是整潔乾淨，絕不會干涉，並確保你不面對一致性的問題和鎖等：

+ 
| 
| 
| DS 1  +------------+   +------------+ 
+---------> |   |   |   | 
      |   | AGGREGATES |   |  reads 
    DS 2  | DW 1  +----------> | DW 2 | +-----------> 
+----------> |   |   |   | 
      |   |   |   | 
+----------> +------------+   +------------+ 
|... DS n 
| 
+ 
where DS : Data Source , DW : Data Warehouse

數據從DW 1遷移 - > DW 2將完全取決於您必須參考的頻繁數據量。

來源

2017-06-19 05:18:11

Amazon Redshift - 複製 - 數據加載與查詢性能問題

回答

相關問題