本身動手寫SQL執行引擎

本身動手寫SQL執行引擎

前言

在閱讀了大量關於數據庫的資料後，筆者不由自主產生了一個造數據庫輪子的想法。來驗證一下本身對於數據庫底層原理的掌握是否牢靠。在筆者的github中給這個database起名爲Freedom。

總體結構

既然造輪子，那固然得從前端的網絡協議交互到後端的文件存儲所有給擼一遍。下面是Freedom實現的總體結構，裏面包含了實現的大體模塊:

最終存儲結構固然是使用經典的B+樹結構。固然在B+樹和文件系統block塊之間的轉換則經過Buffer(Page) Manager來進行。固然了，爲了完成事務，還必需要用WAL協議，其經過Log Manager來操做。
Freedom採用的是索引組織表，經過DruidSQL Parse來將sql翻譯爲對應的索引操做符進而進行對應的語義操做。

MySQL Protocol結構

client/server之間的交互採用的是MySQL協議，這樣很容易就能夠和mysql client以及jdbc進行交互了。

query packet

mysql經過3byte的定長包頭去進行分包，進而解決tcp流的讀取問題。再經過一個sequenceId來再應用層判斷packet是否連續。

result set packet

mysql協議部分最複雜的內容是其對於result set的讀取，在NIO的方式下加劇了複雜性。
Freedom經過設置一系列的讀取狀態能夠比較好的在Netty框架下解決這一問題。

row packet

還有一個較簡單的是對row格式進行讀取，如上圖所示,只須要循序漸進的解析便可。

因爲協議解析部分較爲簡單，在這裏就再也不贅述。

SQL Parse

Freedom採用成熟好用的Druid SQL Parse做爲解析器。事實上，解析sql就是將用文本表示
的sql語義表示爲一系列操做符(這裏限於篇幅緣由，僅僅給出select中where過濾的原理)。

對where的處理

例如where後面的謂詞就能夠表示爲一系列的以樹狀結構組織的SQL表達式，以下圖所示:

當access層經過遊標提供一系列row後，就能夠經過這個樹狀表達式來過濾出符合where要求的數據。Druid採用了Parse中經常使用的visitor很方便的處理上面的表達式計算操做。

對join的處理

對join最簡單處理方案就是對兩張表進行笛卡爾積，而後經過上面的where condition進行過濾，以下圖所示:

Freedom對於縮小笛卡爾積的處理

因爲Freedom採用的是B+樹做爲底層存儲結構，因此能夠經過where謂詞來界定B+樹scan(搜索)的範圍(也即最大搜索key和最小搜索key在B+樹種中的位置)。考慮sql

select a.*,b.* from t_archer as a join t_rider as b where a.id>=3 and a.id<=11 and b.id>=19 and b.id<=31

那麼就能夠界定出在id這個索引上,a的scan範圍爲[3,11],以下圖所示:

b的scan範圍爲[19,31],以下圖所示(假設兩張表數據同樣，便於繪圖):

scan少了從原來的15*15(一共15個元素)次循環減小到4*4次循環,即循環次數減小到7.1%

固然若是存在join condition的話，那麼Freedom在底層cursor遞歸處理的過程當中會預先過濾掉一部分數據，進一步減小上層的過濾。

B+Tree的磁盤結構

leaf磁盤結構

Freedom的B+Tree是存儲到磁盤裏的。考慮到存儲的限制以及不定長的key值，因此會變得很是複雜。Freedom以page爲單位來和磁盤進行交互。葉子節點和非葉子節點都由page承載並刷入磁盤。結構以下所示:

一個元組(tuple/item)在一個page中分爲定長的ItemPointer和不定長的Item兩部分。
其中ItemPointer裏面存儲了對應item的起始偏移和長度。同時ItemPointer和Item如圖所示是向着中心方向進行伸張，這種結構頗有效的組織了非定長Item。

leaf和node節點在Page中的不一樣

雖然leaf和node在page中組織結構一致，但其item包含的項確有區別。因爲Freedom採用的是索引組織表，因此對於leaf在聚簇索引(clusterIndex)和二級索引(secondaryIndex)中對item的表示也有區別,以下圖所示:

其中在二級索引搜索時經過secondaryIndex經過index-key找到對應的clusterId,再經過
clusterId在clusterIndex中找到對應的row記錄。
因爲要落盤，因此Freedom在node節點中的item裏面寫入了index-key對應的pageno,
這樣就能夠容易的從磁盤恢復全部的索引結構了。

B+Tree在文件中的組織

有了Page結構，咱們就能夠將數據承載在一個個page大小的內存裏面，同時還能夠將page刷新到對應的文件裏。有了node.item中的pageno，咱們就能夠較容易的進行文件和內存結構之間的互相映射了。
B+樹在磁盤文件中的組織以下圖所示:

B+樹在內存中相對應的映射結構以下圖所示:

文件page和內存page中的內容基本是一致的,除了一些內存page中特有的字段，例如dirty等。

每一個索引一個B+樹

在Freedom中，每一個索引都是一顆B+樹，對記錄的插入和修改都要對全部的B+樹進行操做。

B+Tree的測試

筆者經過一系列測試case,例如隨機變長記錄對B+樹進行插入並落盤，修復了其中若干個很是詭異的corner case。

B+Tree的todo

筆者這裏只是完成了最簡單的B+樹結構，沒有給其添加併發修改的鎖機制，也沒有在B+樹作操做的時候記錄log來保證B+樹在宕機等災難性狀況下的一致性,因此就算完成了這麼多的工做量，距離一個高併發高可用的bptree還有很是大的距離。

Meta Data

table的元信息由create table所建立。建立以後會將元信息落盤，以便Freedom在重啓的時候加載表信息。每張表的元信息只佔用一頁的空間，依舊複用page結構，主要保存的是聚簇索引和二級索引的信息。元信息對應的Item以下圖所示:

若是想讓mybatis能夠自動生成關於Freedom的代碼，還需實現一些特定的sql來展示Freedom的元信息。這個在筆者另外一個項目rider中有這樣的實現。原理以下圖所示:

實現了上述4類SQL以後，mybatis-generator就能夠經過jdbc從Freedom獲取元信息進而自動生成代碼了。

事務支持

因爲當前Freedom並無保證併發，因此對於事務的支持只作了最簡單的WAL協議。經過記錄redo/undolog從而實現原子性。

redo/undo log協議格式

Freedom在每作一個修改操做時，都會生成一條日誌，其中記錄了修改前(undo)和修改後(redo)的行信息，undo用來回滾,redo用來宕機recover。結構以下圖所示:

WAL協議

WAL協議很好理解，就是在事務commit前將當前事務中所產生的的全部log記錄刷入磁盤。
Freedom天然也作了這個操做，使得能夠在宕機後經過log恢復出全部的數據。

回滾的實現

因爲日誌中記錄了undo，因此對於一個事務的回滾直接經過日誌進行undo便可。以下圖所示:

宕機恢復

Freedom若是在page所有刷盤以後關機，則能夠由經過加載page的方式獲取原來的數據。
但若是忽然宕機,例如kill -9以後，則能夠經過WAL協議中記錄的redo/undo log來從新
恢復全部的數據。因爲時間和精力所限，筆者並無實現基於LSN的檢查點機制。

Freedom運行

git clone https://github.com/alchemystar/Freedom.git
// 並無作打包部署的工做，因此最簡單的方法是在java編輯器裏面
run alchemystar.freedom.engine.server.main

如下是筆者實際運行Freedom的例子:

join查詢

delete回滾

Freedom todo

Freedom還有不少工做沒有完成，例若有層次的鎖機制和MVCC等，因爲工做忙起來就耽擱了。
因而筆者就看了看MySQL源碼的實現理解了一下鎖和MVCC實現原理，並寫了兩篇博客。比起
本身動手擼實在是輕鬆太多了^_。

MVCC

https://my.oschina.net/alchemystar/blog/1927425

二階段鎖

https://my.oschina.net/alchemystar/blog/1438839

尾聲

在造輪子的過程當中一開始是很是有激情很是快樂的。但隨着系統愈來愈龐大，複雜性愈來愈高，進度就會愈來愈慢，還時不時要推翻本身原來的設想並從新設計，而後再協同修改關聯的全部代碼，就如同泥沼，越陷越深。至此，筆者才領悟了軟件工程最重要的實際上是控制複雜度！始終保持簡潔的接口和優雅的設計是實現一個大型系統的必要條件。

收穫與遺憾

此次造輪子的過程基本知足了筆者的初衷，經過寫一個數據庫來學習數據庫。不只僅是加深了理解，最重要的是筆者在寫的過程當中終於明白了數據庫爲何要這麼設計，爲何不那樣設計，僅僅對書本的閱讀可能並不會有這些思考與領悟。
固然，仍是有不少遺憾的，Freedom並無實現鎖機制和MVCC。因爲只能在工做閒暇時間寫，因此斷斷續續寫了一兩個月，工做一忙就將這個項目閒置了。如今將Freedom的設計寫出來，但願你們能有所收穫。

github連接

https://github.com/alchemystar/Freedom