是否應該使用AWS Redshift進行在線查詢？

我有一個使用案例，其中一個相當大的（大於1 TB）的SQL數據庫必須轉移到雲，我想使用Redshift而不是一些RDS解決方案，因爲它便宜一些，而且我處理延遲我的查詢少於10秒。應用程序將很少查詢數據庫 - 大約每天100次。是否應該使用AWS Redshift進行在線查詢？

與RDS相比，使用Redshift會是一個合理的選擇，可以節省成本嗎？

更新：系統將每天更新一次或兩次數據庫。

來源

2017-04-03 emotionull

你剛纔提到，你很少會查詢系統。但是請提一下使用更新還是插入語句來修改系統？答案將很大程度上取決於你是否要插入/更新。 –

@YusufHassan對不起。我應該包括這一點。我已經更新了該問題，以指定該數據庫每天更新一次或兩次。 – emotionull

請接受我的答案，如果它幫助你實現你正在尋找的東西。這樣，它不會在線程中丟失，並會幫助其他有類似問題的人:) –

關於什麼最適合您業務的爭論將永遠存在，您考慮到所有成本和性能權衡會更好地採取最佳決策，但憑藉我以上提供的所有經驗和信息，我可以理直氣壯地讓你知道影響下面的行動將有：

誰來寫紅移表？

如果數據不是實時的，您可以繼續使用Redshift。但是，如果您需要實時數據或您的其他指標依賴於它，例如顯示餘額或忠誠信用點，則Redshift不是理想的選擇。理想情況下，在CPU使用率最低時加載數據。

寫操作是十分緩慢的紅移

作爲柱狀，因此預計散裝寫入將是極爲緩慢。因此，如果您插入數據，請確保在午夜發生，以便CPU不會在ETL任務中使用。

什麼數據集將被查詢？

如果數據集是OLAP，那麼Redshift是理想的。如果數據是OLTP，那麼切換到時不會有性能優點，但它可以節省一些成本。當您的業務增長時，這將是一個痛點

我們需要了解的是，Amazon Redshift與任何基於行的數據倉庫都不相似。它用於分析目的。如果您要生成批量數據（每天以百萬爲單位）並且需要查詢它，那麼它就是您的工具。公司使用Amazon Redshift進行隊列，用戶行爲和趨勢分析，因爲這涉及到查詢大型數據集。列式數據庫用於查詢數百萬條記錄，因爲列式定位已針對查詢龐大數據集進行了優化。

如果您正在存儲OLTP數據集，例如創建的用戶，訂單放置，訂單屬性，首選項，餘額等等，那麼亞馬遜Redshift不是您的工具。寫入速度會很慢，您在查詢這樣的小型OLTP數據集時不會看到任何性能改進。此外，如果您的架構配置爲Master - Slave，則無法承受任何延遲，並且使用RS會導致向從屬設備的數據遷移延遲，因爲它不針對寫入操作進行優化。預計Slave將成爲master的複製品，其中包含幾乎實時的數據，並且使用RS來實現此架構將導致無用的延遲。

鑑於如果您捕獲用戶行爲，點擊和手勢，移動角度，他/她的訪問經緯度...任何生成批量數據，您將查詢巨大的數據集的分析目的，然後紅移是爲你的工具。這些數據點不需要實時，可以每天加載一次或兩次。

我建議去紅移只有當你看到性能的改進。如果你只爲切換成本節約措施，並在未來的業務升級，這將是一項艱鉅的任務，爲您再次遷移到適當的架構。

來源

2017-04-04 06:59:49

AWS已經定位紅移清楚：它是平均數據庫入庫。

總之，AWS期望的管理員：根據數據庫倉庫

按摩數據庫需要
知道如何分片/分割數據庫
知道如何優化數據庫，例如如果需要去歸一化（即轉換或從OLTP（聯機事務處理）友好的OLAP（聯機分析處理）友好。遷移表
移動到紅移時，可能需要更多的磁盤空間，因爲它會創建內部優化額外的索引。

總之，移動紅移也許或許不是給你帶來任何的成本和/或性能優勢，它不是靈丹妙藥。

來源

2017-04-06 15:37:41 mootmoot

這聽起來像根據你的使用情況紅移可能是一個Redshift更像是一個OLAP而不是OLTP數據庫，在非數據庫語言中，它是mor e意味着實時插入或讀取（實時分秒）。紅移也比類似RDS低得多的併發性，但也聽起來並不像這對你的強烈需求。如果你需要

RDS將使意義：

實時單個記錄插入
子第二查詢
高達每秒數千執行查詢。

因爲你可以處理超過1秒的查詢時間，但是在10以下，而且你的查詢工作量不算太大，Redshift應該可以正常工作。

來源

2017-04-09 04:58:27 CraigKerstiens

是否應該使用AWS Redshift進行在線查詢？

回答

相關問題