最近不停的听到SQL Server 2017的各种消息. ( CU1的发布;新的发布策略) , 一直都有一个疑问, 一直是windows平台的主力数据库 SQL Server是如何拥抱Linux的呢? (Access也是被叫做数据库的)
求助于google,找到了SQL Server 官方的博客, 细细阅读了一遍. 原来inside是这样. 这篇文章下面的部分就是对于这篇文章的阅读笔记.
原文地址: https://blogs.technet.microsoft.com/dataplatforminsider/2016/12/16/sql-server-on-linux-how-introduction/
概要
首先要使一直在windows操作系统平台上的SQL Server可以在Linux上运行,就需要引入一个中间的平台抽象层 Platform Abstraction Layer ( PAL ); 参照JAVA的跨平台JVM的理论方式. 我个人理解PAL实际也是类似的一个设计原理.
Given these requirements and the fact that the existing SQL Server OS dependencies would make it very hard to provide a highly capable version of SQL Server outside of Windows in reasonable time it was decided to marry parts of the Microsoft Research (MSR) project Drawbridge with SQL Server’s existing platform layer SQL Server Operating System (SOS) to create what we call the SQLPAL.
那么在SQL Server实现PAL的时候 , 需要考虑当前已有的SQL Server 特性 (RDBMS以及其他性能,安全等特性),使用MSR的Drawbridge以及SQL Server 2005引入的SQLOS两个关键技术来搭建了SQLPAL.
Drawbridge 提供底层操作系统与应用程序之间的抽象
SQLOS 提供内存管理,线程调度以及IO服务.
(这两部分会在后面的文章重点说明.)
这里不得不说, 微软实际在技术储备上还是非常雄厚的, 在早期产品的设计也是比较完善的.这里原文还特别强调了.
We are also changing the SQL Server database engine code to by-pass the Windows libraries and call directly into SQLPAL for resource intensive functionality.
SQL Server
数据库引擎的代码也进行了修改, 用以将原有调用Windows库的代码修改为在SQLPAL上运行.( 针对资源密集型)言外之意应该在ssrs等应用上并没有那么多windows库的调用.
宏观层面使用上面的技术进行中间平台的搭建. 那么在更深入一级的层面, 运行在Linux上实际上就是要删除或者抽象对应windows平台的依赖.对应windows平台的依赖, 主要有3个部分: win32/NT内核/windows应用程序库 ;
接下来就是干货了. Inside PAL
SQLOS(SOS)
SQLOS是在SQL Server 2005发行版中引入的. 在SQL Server 引擎和windows操作系统间创建的一个SQL操作系统平台层.
主要负责: 用户模式线程调度,内存管理以及同步(更多参考SQLOS)
引入SQLOS的关键原因是可以为用户提供一套集中的低级别管理和诊断功能( DMV以及扩展事件, XEvent子集)
优点: 提高了性能并对管理和调试提供了工具
缺点: 没有对操作系统提供适当的抽象依赖,将windows库通过SQLOS暴露给了数据库引擎(下图里面能看到这点)
原文引用的是另外一张图, 看了看大同小异, 我还是使用了sql server 2005发布版的说明图.
Drawbridge
Drawbridge是微软的一个研究项目,主要针对解决在同一硬件上托管多个虚拟机时如何降低虚拟化资源开销.(具体参考Drawbridge)
我个人理解为,这个是一个微软自己研究的容器技术.
上述的两个SQLOS(SOS)和Drawbridge都实现了图中的这5个技术点
有重叠的部分就需要取舍. 最终SQL Server 团队采取了混合策略.将SQLOS+Drawbridge+Library OS来创建 SQLPAL.其中sql server不需要的库操作系统部分,将被删除.
最终新的架构由一组SOS直接API组成,它们不经过任何Win32或NT系统调用。对于没有SOS直接API的代码,他们将通过托管的Windows API(如MSXML)或NTUM(NT用户模式API - 这是1500+的Win32和NT系统调用)。所有子系统如存储,网络或资源管理都将基于SOS,并将在SOS direct和NTUM API之间共享。
此架构的特征:
进程模型
下图显示了运行时地址空间的样子。主机扩展只是一个本地的Linux应用程序。当主机扩展启动时,加载并初始化SQLPAL,然后SQLPAL启动SQL Server。SQLPAL可以启动软件隔离进程,这些进程只是在同一地址空间内运行的线程和分配的集合。我们将其用于像SQLDumper这样的事情,SQLDumper是SQL Server遇到问题时运行的应用程序,用于收集开明的故障转储。
这样在Linux上SQL Server就可以运行起来了.
文章最后还提到了SQLPAL的演变过程, 简而言之, 在未来的SQL Server中将删除SOS,取而代之的将是新的SQLPAL.