SQL Server架构演变（至SQL Server 2017）

一、 概述

到SQL Server 2017为止，sqlserver架构经历了以下阶段：

• 直接用Windows对SQL Server进行资源管理：这个阶段没有一个特定的名称叫法，SQL Server服务无法突破Windows内核对资源的限制
• UMS阶段：增加了一层User Mode Scheduler，自行管理scheduler
• SQL OS阶段：SQL Server自行进行任务调度及内存管理
• Drawbridge的出现：研究性项目，用于实现应用的沙盒，最开始不是为SQL Server专门设计的，但在SQL Server 2017中扮演中非常重要的角色
• SQL PAL的出现：SQL Server 2017整合了SQL OS和Drawbridge，进行底层封装，形成了SQL PAL层

 

二、 SQL Server架构演进

1. sqlserver 6.5前

• 直接调用windows 32位 API
• 依赖操作系统scheduler
• 可扩展性差

 

2. sqlserver 7.0~sqlserver 2000

• 增加了一层UMS
• 自行管理scheduler
• CPU使用更高效

SQL Server 2005前，sqlserver服务是以一个用户态进程运行在Windows操作系统中，这个服务进程与其他普通的进程没有任何差异，它依赖于操作系统内核对底层硬件资源进行管理和交互，SQL Server服务本身没有对系统资源的管理能力。

这个架构最大的缺点是SQL Server服务本身无法突破Windows内核对系统资源使用的限制，阻碍了SQL Server系统性能的进一步提升。

 

3. sqlserver 2005~sqlserver 2016

• 将UMS改为了SQLOS
• UMS+各种资源管理

为了解决上面的问题和获取更好的性能，微软花大力气抽象了一个中间层对系统硬件资源进行调度和管理，并发布在SQL Server 2005版本中，也因此2005版本经历了长达5年的时间才得以面世。这个中间层叫做SQL OS（也叫SOS）。

SQL OS的主要职责包括：Processor Scheduling，Memory Management，Network，Disk I/O使得SQL Server性能最大化（可以使得SQL Server用户进程最大限度的充分利用操作系统硬件资源）。

SQL Server 2005赋予了SQL OS非常全面的资源管理功能，具体包括：

• Deadlock Monitor：死锁监控
• Resource Monitor：资源监控
• Lazy Writer：延迟写，将随机I/O写，转化为顺序I/O写
• Scheduler Monitor：调度器监控
• Buffer Pool：缓存池
• Memory Manager：内存管理
• Scheduling：调度
• Synchronization Service：同步服务
• Lock Manager：锁管理器
• I/O：I/O资源管理

详细SQLOS API架构如下图所示： 

有了SQL OS层次的抽象，得以在数据库内部实现对系统资源的集中管理，摆脱系统内核对SQL Server资源使用的限制，使得SQL Server服务对系统资源有了很强的控制能力。SQL Server 2005性能因此有了大幅提升，成了sqlserver历史上划时代的版本，也为SQL Server 2017能够提供跨平台能力提供了可能性，可以毫不夸张的说，没有SQL OS的出现，微软不可能在如此短的时间内实现Linux版的SQL Server。

 

4. 过渡篇——Drawbridge

微软研究院在2011年9月建立了一个全新的研究性项目Drawbridge，目的是提供应用程序新的虚拟化资源隔离解决方案，减少虚拟资源的使用，使得在同一个硬件主机上，可以运行更多的虚拟机（类似Docker）。

Drawbridge其中一个非常重要的组件Library OS仅依靠约50个底层内核应用二进制接口（ABI：Application Binary Interface）实现了一千多个常用的Windows API，同时还具备了为其他组件提供宿主的能力，比如：MSXML和CLR等组件。 在Windows 10版本中存在着Drawbridge的大量应用。 

 

5. sqlserver 2017

• 将SQLOS改为了SQLPAL，使得可以跨平台

 

三、 SQL PAL（Platform Abstract Layer）

 

1. 概要与架构

SQL Server数据库团队基于Drawbridge项目与SQL OS进行了重写和充分的融合，形成了新一代数据库底层抽象和封装SQL PAL，同时将上层逻辑代码移植到SQL PAL之上。如此，微软只需要确保SQL PAL层可以在Windows平台和Linux平台运行良好，SQL Server即使运行在Linux平台，也无需修改SQL Server本身的代码，使其与平台无关。

能做到这一点完全是由Drawbridge中的ABI来实现的，这些ABI我们叫着Host Extension，所以为了支持SQL Server 2017的跨平台特性，微软只需要实现基于Windows平台的Host Extension和Linux平台的Host Extension，这样做最大的好处是：

• 大大缩短开发周期：微软无需对SQL Server本身做任何的代码修改就可以将SQL Server移植到Linux平台。
• 产品功能一贯性：对SQL Server新功能、新特性的支持，无需对两个平台进行重复开发，Windows平台支持了，Linux平台也就支持了，保持了产品功能的一致性。
• 良好的后期维护性：假如SQL Server存在某个Bug，只需要修复SQL Server本身，那么Windows平台，Linux平台上相应的Bug也同样被修复掉了，具备良好的可维护性。 

以下是SQL PAL功能更为详细的描述架构图： 

从这张图，我们可以清晰的看到SQL PAL层次对于Host Extension的调用，以及构建在这层次之上的SQL Server服务，包括：数据库引擎、集成服务、分析服务和报表服务。

 

2. SQL PAL性能影响

根据TPC-H测试来看，SQL Server 2017相对于SQL Server 2016，性能不降反升。

TPC-H性能测试

从TPC-H测试数据来看，相对于SQL Server 2016，不论是性能和性价比，都有小幅提升： 

TPC官网公布的性能数据截图

微软内部测试

以下展示微软内部测试实例，在拥有一台12 TB内存，480个逻辑CPU的机器上，处理30 TB，2500亿条数据的8个字段的3种类型复杂统计汇总查询，耗时仅用18秒。由此可见，性能还是相当强劲的： 

 

参考

http://mysql.taobao.org/monthly/2017/10/05/