Azure碰撞數據庫cpu的限制太容易了

-1

背景簡介： - 我們有一個SAAS解決方案，包含以下主要組件。 1.我們有一個Web門戶後端，管理員可以在其中編輯數據。 2.我們有一個由移動設備調用的Web API。移動設備跟蹤或報告學生閱讀進度Azure碰撞數據庫cpu的限制太容易了

到目前爲止，該解決方案已託管在虛擬服務器上。現在我們正在將解決方案遷移到Azure框架，以便我們可以利用彈性數據庫池的可伸縮性。我們正在使用事件主題來處理來自移動設備的大量帖子，當帖子可以異步處理時，，但有一些帖子需要同步處理，並且我們發現Azure的面料在涉及多個併發連接。

問題的例子： -

所以當Azure中運行類似以下的查詢： -

SELECT q.Category, COUNT(*) 
FROM Question q 
JOIN Answer a 
ON a.QuestionId = q.QuestionId 
GROUP BY q.Category 
ORDER BY q.Category

的SQL CPU的峯值97％以上，在所有的下列情況： -
1. DTU爲50，並有多個併發呼叫。
2. DTU是1500，並有5個或更多併發呼叫。
3. DTU是4000，並有20個或更多的併發呼叫。

因此，我們向微軟公司打了一個支持電話。我們花了超過一週的時間從sql統計數據和索引到web api定價層。畢竟，我們仍然拿出了上述情況下CPU在SQL數據庫中達到峯值的證據。

這導致了不可避免的「重寫大系統」這種爭論。

所以潛在的問題是彈性數據庫池似乎無法在標準SQL數據庫的能力附近執行任何操作。另外，獨立數據庫的性能似乎與虛擬服務器的性能無關。

這非常令人沮喪，因爲爲了保持性能和增加可伸縮性，推薦使用彈性數據庫池。我們目前在一臺虛擬服務器上運行700多個客戶;並期望爲每個客戶創建一個分片數據庫。這個想法是我們可以從數百個客戶擴展到數以萬計的客戶。實際上，我們正努力讓Azure結構在我們擁有的虛擬服務器性能附近進行。所以這個問題就是問有沒有人有足夠的經驗讓Azure以合理的速度執行非平凡的任務？（最好不用重新編寫大塊的系統）

來源

2016-10-07 David Mawer

有沒有？在你的問題上標記。清理它或它會關閉。 – Paparazzi

從單個數據庫實例遷移到池並不總是提升和轉換。您必須考慮當前如何處理數據相關路由。那麼你必須考慮你的數據庫連接的連接範圍（主控制器與租戶連接）。如果MS建議重新編寫大量的應用程序，他們可能會發現一些您可能尚未準備好進行彈性縮放的區域。如果您想將問題分解爲單元，我很樂意回答如何從一個實例遷移到多個實例。 –

謝謝@ShannonLowder，我意識到你是對的。我希望重構不是必需的，但我現在已經接受它是不可避免的。 –

所以簡而言之，事實證明，sql數據池的工作方式需要更多的優化查詢。

DTU的測量方式意味着任何非常健壯的SQL工作都將在sql數據池之外進行處理;但數據池內的數據操作應該儘可能的光滑（索引，統計數據更新，連接中可能的最少字段）。

事實證明，這只是Azure的工作方式。

來源

2016-10-10 09:17:19

將SQL數據庫遷移到雲時需要思考轉變。

在內部環境中，我們習慣於功能強大的機器，這些機器足夠強壯以應對激烈的工作負載。這是因爲物理機器是用所需的資源構建的，以處理大量處理大量工作量（爲構建他們需要處理的最大任務而非最小任務而構建）。由於資源的過度可用性，我們經常允許低效率工作到查詢和底層架構中。由於資源過度可用，影響往往很小。

但是，然後您嘗試將這些相同的數據庫移動到Azure中，並且事情也不會如此。請記住，Azure是一種按使用付費的模式。您爲Y資源支付X，並且當您需要更多資源時，您會爲更多Y支付更多X.由於此模型，您必須考慮在數據庫中執行的所有操作都會使您花費更多資金。每個查詢花費你的錢。每一項低效都會讓你花更多的錢。等等。當每個月明確支付資源時，我們傾向於購買（通常用於最小的任務），因爲我們覺得我們正在浪費資金。這意味着當需要運行偶爾的大任務時，我們沒有足夠的資源來處理它，並且性能下降。這導致我們認爲Azure的成本更高，但性能更差。

因此，如果您願意爲此付費，那麼爲了改善您的情況，您可以隨時增加Azure中的資源。或者，您可以像其他人一樣建議和優化您的查詢和底層架構，並在您每次執行時節省成本。

來源

2017-05-03 16:27:53 Trevor

Azure碰撞數據庫cpu的限制太容易了

回答

相關問題