Microsoft SQL Azure论文笔记

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

基本架构

1. global shard map manager：也叫global partition manager用来存储所有数据的shard信息，这个shard我们后面会讲到
2. Database Engine：一个个单独鱼腥SQL Server的物理进程，他们之间相互隔离
3. Protocal Gateway：协议网关负责将用户的请求转发到对应的replica上
4. 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是面向多租户的云数据库，因此要限制客户使用的系统资源：

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

参考链接

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