2014-08-28 103 views
3

新的Azure SQL數據庫服務看起來不錯。不過,我正在努力研究它們的可擴展性。新的Azure SQL數據庫服務,如何擴展和DTU是什麼

因此,例如,假設200個併發用戶系統。

對於標準

Workgroup and cloud applications with "multiple" concurrent transactions 

對於高級

Mission-critical, high transactional volume with "many" concurrent users 

什麼是 「多」 與 「多」 的意思嗎?

另外Standard/S1提供15個DTU,而Standard/S2提供50個DTU。這是什麼意思?

回到我的200用戶示例,我應該選擇什麼選項?

Azure SQL Database Link

感謝

編輯

Useful page on definitions

然而什麼是 「最大會話數」?這是併發連接的數量嗎?

回答

2

如果不做測試就很難說。對於200位用戶,我假設你的意思是200人同時坐在電腦前做事,而不是200人每天登錄兩次。 S2允許每秒發生49次交易,這聽起來正確,但您需要測試。也做了很多緩存不能傷害。

+0

謝謝你。是的,我的意思是,我同意測試。我使用JMeter。 「Max Sessions」是什麼意思?它看起來像連接的數量,無論如何,越多你付出越多。只是想知道這是否與併發有關。 – SamJolly 2014-08-29 00:59:46

+0

我認爲最大會話對應於最大連接數。考慮到你通常使用連接池,所以它不符合用戶。 – Craig 2014-08-29 01:03:44

+0

我想知道當前使用的Web SQL數據庫產品的「Max Sessions」是什麼。是的,連接池將被使用,默認情況下,我猜是在EF/MSSQL設置中。所以如果「最大會話」數字很低,那麼查詢會排隊很多。他們可以超時和失敗嗎? – SamJolly 2014-08-29 12:53:27

4

在Azure SQL數據庫中有一些很棒的MSDN文章,特別是這對於DTU有一個很好的起點。 http://msdn.microsoft.com/en-us/library/azure/dn741336.aspxhttp://channel9.msdn.com/Series/Windows-Azure-Storage-SQL-Database-Tutorials/Scott-Klein-Video-02

簡而言之,它是瞭解支持每個性能級別的資源的一種方式。我們在與Azure SQL數據庫客戶交談時知道的一件事是,他們是一個多元化的組織。有些人對最絕對的細節,內核,內存和IOPS感到滿意 - 而其他人則更多地總結了信息的概要。沒有一種適合所有人的方式。 DTU適用於此後組。

無論如何,雲的好處之一就是從一個服務層和性能級別開始,並且可以輕鬆地迭代。在Azure SQL數據庫中,您可以在應用程序啓動時更改性能級別。在更改過程中,當DB連接斷開時,通常會少於一秒的時間。我們服務中用於從服務層/性能級別移動數據庫的內部工作流遵循與數據中心內節點故障轉移工作流相同的模式。節點故障轉移始終獨立於服務層更改發生。換句話說,相對於過去的經驗,你不應該注意到這方面的任何不同。

如果DTU不是您的事情,我們也有更詳細的基準工作負載,可能會有吸引力。 http://msdn.microsoft.com/en-us/library/azure/dn741327.aspx

感謝蓋伊

+0

Guy,真的很感謝你的反饋。我們目前收到的問題之一是查詢性能非常不穩定。我們目前使用SQL數據庫Web,而且我們的用戶羣並不大,而且數據庫是新的,MB大小。我已經看到會員服務GetUser SP從1秒到4秒不等(由NewRelic在SQL層上測量)。我有點懷疑我可能在數據庫中遭受某種形式的爭用,因此這種變化是可變的。因此,我希望新標準S1的性能更高。 – SamJolly 2014-09-03 01:26:34

+1

只看了你最後一個鏈接。有用的,但我不確定爲什麼使用不同的吞吐量單位,即交易/小時,交易/分鐘和交易/秒。爲什麼不用相同的單位即事務/秒來表達它呢?指定當前的SQL數據庫Web和業務實例也是最有趣的。人們希望看到SQL數據庫Web的大幅增長。再次感謝 – SamJolly 2014-09-03 01:34:07

0

DTU基於CPU,內存,讀取和寫入的混合度量。隨着DTU的增加,性能水平提供的功率也會增加。 Azure對併發連接,內存,IO和CPU使用率有不同的限制。哪一級有所回暖實際上取決於

  1. #concurrent用戶
  2. 登錄速度
  3. IO速度
  4. CPU使用率
  5. 數據庫大小

例如,如果你是設計一個系統,其中多個用戶正在閱讀,並且只有少數作家,並且如果您的應用程序中間層可以儘可能緩存數據,並且只有sele ctive查詢/應用程序重新啓動命中數據庫,然後您可能不必太擔心IO和CPU使用情況。

如果許多用戶在同一時間點擊數據庫,您可能會遇到併發連接限制,並且請求將受到限制。如果您可以控制用戶請求到達您的應用程序中的數據庫,那麼這應該不成問題。

登錄率:取決於數據更改的數量(包括系統中的其他數據泵送)。我已經看到應用程序穩定地抽取數據和數據一次抽完。再次選擇正確的DTU取決於如何在應用程序端進行限制並獲得穩定的速率。

數據庫大小:Basic,standard和premium具有不同的允許的最大大小,這是另一個決定性因素。使用表格壓縮功能有助於減小總大小,從而減少總IO。內存:調整exsnive查詢(連接,排序等),啓用鎖定升級/ nolock掃描有助於控制內存使用情況。

人們通常在數據庫系統中犯的常見錯誤是擴大其數據庫,而不是調整查詢和應用程序邏輯。因此,測試,監控具有不同DTU限制的資源/查詢是處理此問題的最佳方法。

如果選擇了錯誤的DTU,不用擔心,你總能擴展在SQL DB /下和它是完全在線操作

而且,除非一個強有力的理由遷移到V12以獲得更好的性能和特徵。