工作需要，要評估Azure SQL DB的配置，所以整理一下網上搜集的信息，由於雲產品更新迭代很快，所以今天的內容可能在不久的將來就會變更，但是這個不影響本質。
本文歸屬：SQL Azure 工作積累（1）——添加用戶到Azure SQL DB
簡介
截止發文之時， Azure SQL DB有兩種付費模式，一種是vCore，一種是DTU，但是由於公司使用vCore爲主，所以先考慮vCore。
vCore又可以分爲三種主要pricing tier，General Purpose（GP）、Business Critical（BC）和Hyperscale。 GP和BC主要差距在I/O，BC的I/O遠高於GP（當前文檔的頂配數據分別是204800和20000）。但是Hyperscale的強項在存儲空間，因爲GP和BC頂配也只能支持4TB，對於我們公司和一些DW項目而言實在太少了。所以需要我評估Hyperscale。微軟的Hyperscale的競爭對手是Amazon Aurora。
在不考慮費用的前提下，Hyperscale相對於前面兩個而言，強在空間，而且I/O性能比GP好。其次，它還帶有不錯的HA功能，也就是高可用。
傳統模式的高可用
傳統的數據庫高可用是通過異步或同步模式，進行多個副本的維護，達到故障轉移（Failover）的作用從而實現高可用。
傳統的方式通過集羣的方式實現副本同步及故障轉移。這種方式有兩個主要問題，一是數據庫及相關的核心文件是否有多重保護。二是讀寫分離甚至並行寫。
過去傳統的Windows集羣使用共享存儲，數據文件只有一份，會出現單點故障，後來出現SQL Server高可用組之後，可以不用共享存儲，這樣數據安全有保障。對於讀寫分離，可用性組是很好的例子，同時具備高可用和災難恢復，即HA和DR。
不過在雲時代，這種傳統方式略顯低效。那雲時代會怎麼做呢？
Hyperscale的優勢
官方文檔寫的很詳細，不過對於我所在的項目，有些是我比較看重的：
- 最大數據庫大小：100TB， 其他兩種只能支持4TB。
- 瞬間備份：基於Azure Blob存儲的文件快照，不影響I/O且不存在大小限制。
- 快速恢復：相比起其他的數小時甚至以天爲單位，Hyperscale只需要幾分鐘。
- 性能不差：更高log吞吐量和更快的快速事務提交，因爲關係型數據庫的90%開銷實際上是寫入日誌上面，所以對日誌的優化很有必要。
- 快速橫向擴展：通過添加只讀副本實現分攤純讀負載和提供更好的容災能力。
- 成本：GP和BC的成本包含了存儲空間，不管你實際用多少，雖然後續可以調。但是Hyperscale只對實際消耗計算費用。
- 快速scale up和scale down：scale up就是調高配置，scale down就是調低配置，實測過程中，BC/GP 對於TB級別的庫，scale up/down都是1個多小時，如果GP→BC，本人項目中最高是6個小時。Hyperscale的官方說明是TB級別的數據庫只需要分鐘級別。這個有待測試。
- 支持混合工作負載：Azure SQL DB實際上就是SQL Server的雲版，它天生就對OLTP系統做設計和優化，對於OLAP類型，適合使用Azure SQL DW， 不過使用Hyperscale，可以實現單環境混合使用。
費用
雲產品的使用很講究費用，因爲是用多少給多少，所以更加需要精打細算。因爲存在副本的概念，所以跟BC/GP的付費不同，Hyperscale是按照副本數量計費的。Hyperscale默認是1讀1寫兩副本，這部分是一個費用。後續調整的副本數再額外計費，最高總副本數是5個。
Hyperscale的運行模式
傳統的SQL Server，建議對大型數據庫創建多個數據文件組或數據文件並放到獨立的物理磁盤。而在Hyperscale中，微軟會幫你自動完成這種文件部署，而且你看到的數據文件，實際上是一個page server，當最後一個page server達到80%的使用率時，Hyperscale會添加另外一個新的page server，顯示給用戶看到的就是一個新的數據文件。而且底層技術上，會有兩個page servers做冗餘。
但是Hyperscale相比起非PaaS版本的SQL Server而言，I/O並非最好，另外它依舊不支持某些特性比如TDE或者bulk insert模式。
Hyperscale支持讀寫分離，其底層使用AlwaysOn可用性組，但是比起傳統的方式，其Caching有點麻煩，它的data page是由log service來變更，極端情況下可能讀副本上的數據並非最新的。
何時使用Hyperscale
當滿足以下全部條件時你可以考慮使用Hyperscale：
- 你的應用程序兼容SQL Server
- 純讀非常高，使用Hyperscale的讀寫分離可以充分利用只讀副本的優勢，同時減少對讀寫副本（也就是主副本）帶來的壓力。
- 只讀查詢可以容忍數秒的延時。
- 主副本的瓶頸並非在事務日誌的寫性能。
- 你的數據庫預期或者現在已經遠超於4TB空間。
Hyperscale是單向遷移，也就是說不想BC/GP那樣可以換來換去，從BC/GP換到Hyperscale之後是不能換回去，所以在遷移之前，可以做一個備份然後把備份進行遷移。
小結
本文作爲初步研究Hyperscale的文章，不打算寫太詳細，而且官方文檔很多都有，後續在工作過程中會把一些針對性的問題專門拿出來分享。