作爲替換或添加的紅移

Question

一位同事已經構建了一個帶有PHP框架的Web應用程序，我們可以在其中配置對其他系統的一些API調用。它們在夜間運行，將新數據導入Postgres數據庫。由於Postgres是一個OLTP數據庫，不是爲分析而開發的，所以我開始閱讀關於Redshift的內容。但我無法弄清楚所有這些如何結合在一起。

哦和分析，我們會看看PowerBI可能使用DirectQuery紅移。但正如我所看到的，Postgres沒有這樣的事情。

所以對於我的問題，我將一切都分爲四個部分：

• 應用程序的應用程序（用戶模式的API調用）（登錄，接口配置API調用）
• 使用用戶數據
• 數據
• 數據倉庫（存儲用於分析數據）

 
Solution | Application | Userdata | Data   | Datawarehouse 
-------- | ----------- | ---------- | ------------- | ---------------- 
Now  | PHP  | Postgres | Postgres  | 
1.  | PHP  | Postgres | Postgres  | Redshift 
2.  | PHP  | Postgres |    | Redshift 
3.  | PHP  | Redshift |    | Redshift 

（來自蜜蜂供以後分析的答案）

所以問題是：什麼可能的解決方案是「正確」的呢？我可以使用我們擁有的基礎設施，只需添加Redshift。但隨後我將存儲成本加倍。我可以將應用程序數據存儲在較小的數據庫中，並將來自API的數據直接存儲到Redshift中，或者使用Redshift作爲唯一的數據庫。

Answer 1

你的問題是不是你打算如何使用數據庫是很清楚，不過最好的建議是儘量使用一個「正常」的數據庫（在你的情況下，PostgreSQL的）一切。

如果您發現您的分析是時間太長，你有百萬或數十億數據庫中的行的，你可以再考慮也使用亞馬遜紅移更快的分析查詢。如果您的查詢是隻讀的，您也可以考慮使用Amazon Athena，它可以直接從存儲在Amazon S3中的文件中讀取數據。

Answer 2

Postgres數據庫在這種情況下的用途是什麼？

我建議寫API的輸出直接調用S3並裝入紅移從那裏。

如果這些API響應使用JSON（可能是），則可能需要將它們壓縮爲CSV以加載到Redshift中。 Redshift的JSON加載非常有限。

Answer 3

兩個系統有不同的後端紅外和用於一些非常具體的用途。雖然它們在處理少量數據時可能會互換使用，但在涉及大量讀取/寫入時會發生劇烈變化。

在這裏，我認爲當你說你正在使用Postgres的，你大概是一排方向。

爲了寫入批量數據，行DB是優選的，因爲它是其中作爲柱DB是如果您的操作包括查詢多個行（用於分析目的的典型的要求）中使用寫密集的。最佳組合始終保持將事務數據存儲在面向行的數據庫中，將用於分析目的所需的某些表遷移到列數據庫並在那裏運行分析查詢。這可能聽起來荒謬而昂貴，但如果一些公司不希望與事務性數據或分析數據妥協，那麼這些公司會如何執行。

，如果你是涉及重（金融）交易產品爲主的公司，你捕捉user_persona還有，他們分別跨越兩個行和列導向的架構分裂。

一排DB是寫密集型。當應用程序批量交易 寫入語句時，它必須寫在表格上，沒有任何滯後。我 肯定，你將有多個master_slave配置爲好，這樣 數據必須被複制到奴隸，以及和太，在 實時。

現在必須明白分析數據與交易數據非常不同。交易數據量不是很大 - 讓我們說，這將有一個排在訂單表中創建並映射user_id與放置每個訂單的一些基本order_details;但分析數據 - 每次用戶登錄應用程序時都會生成屏幕上的點擊模式，發送通知的詳細信息等;是龐大的，不能像我們存儲交易數據一樣存儲。

的柱狀方向（如在亞馬遜RS）被讀取密集 - 用於分析 數據的典型要求，因爲大量的行的將對於給定的 user_set檢索 - 所有通知的細節發送，或者所有用戶瀏覽/點擊屏幕 。圓柱形DB是爲滿足 這樣的要求而量身定做的。

堆積在柱狀DB寫入慢;但由於它現在主要處理分析數據 - 沒有實時數據並不重要。分析需要時間和數據，直到current_date-1或延遲爲n小時總是可以引用繪製用戶角色。

對於擁有大量數據集的大型公司來說，需要維護一個權衡。我希望你現在可以對如何解決這個問題有個微弱的想法。