Microsoft SQL Azure

本笔记出自论文《Extreme Scale with Full SQL Language Support in Microsoft SQL Azure》和一些网络资料。论文在开头就提到了，很多互联网行业做出的存储产品如Google Bigtable、Yahoo PNUTS、Amazon Dynamo等，其提供的ACID事务、一致性保证是和传统的关系型数据库有很大区别的。互联网行业通过其上层业务的抽象，将一致性及事务限制在特定的consistency domain中，从而支持大规模的存储需求。如Bigtable的EG，以及本文将要讲到的partition key。

Azure SQL的设计初衷，就是为了在享受大规模分布式存储的有点的同时，仍能保有传统关系型数据库的大部分特性。

基本架构

global shard map manager：也叫global partition manager用来存储所有数据的shard信息，这个shard我们后面会讲到
Database Engine：一个个单独鱼腥SQL Server的物理进程，他们之间相互隔离
Protocal Gateway：协议网关负责将用户的请求转发到对应的replica上
Distributed Fabric：分布式基础组件，用以维护节点状态，选主等等。

数据模型

Azure SQL将数据划分为多个分区，通过限制事务只能在一个分区执行来规避分布式事务。集群数据多副本采用Quorum，每份数据都会有primary replica。

Azure SQL通过表（这里只广义上的表，既可以值关系型数据库中的表table，也可以指存储Blob，Queues等）的某key作为索引，我们称之为Partition key。将表中的数据打散到后端不同存储节点上。只要partition key相同，则数据会分布在同一台服务器上。

通过这种方式，同一partition key的数据shard总是分布在一台服务器上，Azure SQL可以天生很好的支持READ COMMITTED隔离级别，但是如果想使用更高的隔离级别，比如REPEATABLE READ，就必须要持有垮shard的锁，这会使性能下降很多。

另外Azure SQL还支持快照隔离

复制

Azure SQL采用Quorum协议，所有的sql语句经过主副本下发，三副本的数据至少成功两副本才能返回，主副本在发送事务的时候会带上事务提交顺序号（Commit Sequence Number CSN），从而作为回复和回滚的依据。

如果节点发生了故障，之前讲到的global partition manager会执行故障分区的Reconfigration，首先它会选择一台负载较轻的机器增加到当前副本集中，拷贝数据，然后重新配置Quorum。由于使用了Quorum，所以数据在集群中的复制优先级也不一样(有的副本复制了三份，有的只复制了2份)，优先级也是由global partition manager来控制的。

显而易见的是，集群负载较大时，primary replica会成为热点，这时global partition manager会从三副本中重新选择一个副本，提升为主primary replica。由于不涉及副本数据的迁移，这种负载均衡较为迅速。

多租户

Azure SQL是面向多租户的云数据库，因此要限制客户使用的系统资源：

系统资源的监控与分配，包括CPU、内存、存储QOS等等
SQL数据库的容量限制，如果超过容量则不能写入。
后端存储节点Database Engine的资源分配，不能写满后端存储节点。

参考链接

Azure SQL Data partitioning strategies
SET TRANSACTION ISOLATION LEVEL (Transact-SQL)
Distributed Storage: How SQL Azure Replicas Work