最近不停的聽到SQL Server 2017的各種訊息. ( CU1的釋出;新的釋出策略) , 一直都有一個疑問, 一直是windows平臺的主力資料庫 SQL Server是如何擁抱Linux的呢? (Access也是被叫做資料庫的)

求助於google,找到了SQL Server 官方的部落格, 細細閱讀了一遍. 原來inside是這樣. 這篇文章下面的部分就是對於這篇文章的閱讀筆記.

概要

首先要使一直在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實現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之間共享。

此架構的特徵:

• 正在執行的所有東西歸結為相同的平臺彙編程式碼。CPU無法區分提供Win32功能的程式碼與SQL Server或本機Linux程式碼之間的區別。
• 架構顯示分層.如果執行效能為先的SQL Server中的程式碼, 可以通過SOS Direct API直接使用非常少量的彙編程式來設定堆疊並進行處理即可.
• 所有資源都使用SQLPAL管理(記憶體分配和執行緒都將由SQL PAL控制). 在此之前是無法做到的.
• 對於Linux上的SQL Server, 使用大約81MB的未壓縮Windows庫. SQLPAL本身目前僅有 8MB

程序模型

下圖顯示了執行時地址空間的樣子。主機擴充套件只是一個本地的Linux應用程式。當主機擴充套件啟動時，載入並初始化SQLPAL，然後SQLPAL啟動SQL Server。SQLPAL可以啟動軟體隔離程序，這些程序只是在同一地址空間內執行的執行緒和分配的集合。我們將其用於像SQLDumper這樣的事情，SQLDumper是SQL Server遇到問題時執行的應用程式，用於收集開明的故障轉儲。

 這樣在Linux上SQL Server就可以執行起來了.

文章最後還提到了SQLPAL的演變過程, 簡而言之, 在未來的SQL Server中將刪除SOS,取而代之的將是新的SQLPAL.