工作需要，要评估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来变更，极端情况下可能读副本上的数据并非最新的。