1. 程式人生 > >自己動手寫SQL執行引擎

自己動手寫SQL執行引擎

# 自己動手寫SQL執行引擎 ## 前言 在閱讀了大量關於資料庫的資料後,筆者情不自禁產生了一個造資料庫輪子的想法。來驗證一下自己對於資料庫底層原理的掌握是否牢靠。在筆者的github中給這個database起名為Freedom。 ## 整體結構 既然造輪子,那當然得從前端的網路協議互動到後端的檔案儲存全部給擼一遍。下面是Freedom實現的整體結構,裡面包含了實現的大致模組: ![](https://oscimg.oschina.net/oscnet/up-83cf4cad225751c169cc260f1be5de72b0f.png) 最終儲存結構當然是使用經典的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是否連續。 ![](https://oscimg.oschina.net/oscnet/up-0b7d17469107496fd399312ec786141899d.png) ### result set packet mysql協議部分最複雜的內容是其對於result set的讀取,在NIO的方式下加重了複雜性。 Freedom通過設定一系列的讀取狀態可以比較好的在Netty框架下解決這一問題。 ![](https://oscimg.oschina.net/oscnet/up-fc9841db0119d848e39f84dd8830c5b81dd.png) ### row packet 還有一個較簡單的是對row格式進行讀取,如上圖所示,只需要按部就班的解析即可。 ![](https://oscimg.oschina.net/oscnet/up-9ba7a4e3db0a44f4dffd5dc904b731f6d6c.png) 由於協議解析部分較為簡單,在這裡就不再贅述。 ## SQL Parse Freedom採用成熟好用的Druid SQL Parse作為解析器。事實上,解析sql就是將用文字表示 的sql語義表示為一系列操作符(這裡限於篇幅原因,僅僅給出select中where過濾的原理)。 ### 對where的處理 例如where後面的謂詞就可以表示為一系列的以樹狀結構組織的SQL表示式,如下圖所示: ![](https://oscimg.oschina.net/oscnet/up-fd6c823889c9ecc83995de0d90e7804daf9.png) 當access層通過遊標提供一系列row後,就可以通過這個樹狀表示式來過濾出符合where要求的資料。Druid採用了Parse中常用的visitor很方便的處理上面的表示式計算操作。 ### 對join的處理 對join最簡單處理方案就是對兩張表進行笛卡爾積,然後通過上面的where condition進行過濾,如下圖所示: ![](https://oscimg.oschina.net/oscnet/up-3509db89d2ccfe1584e4ce3d88eb156bab1.png) ### 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 b.id and b.id>=19 b.id<=31 ``` 那麼就可以界定出在id這個索引上,a的scan範圍為[3,11],如下圖所示: ![](https://oscimg.oschina.net/oscnet/up-644fdc65e4a183a9af9e9c6c8775106a15c.png) b的scan範圍為[19,31],如下圖所示(假設兩張表資料一樣,便於繪圖): ![](https://oscimg.oschina.net/oscnet/up-d6bb3434b260ab8246a3bcee8255274a4ee.png) scan少了從原來的15\*15(一共15個元素)次迴圈減少到4\*4次迴圈,即迴圈次數減少到7.1% 當然如果存在join condition的話,那麼Freedom在底層cursor遞迴處理的過程中會預先過濾掉一部分資料,進一步減少上層的過濾。 # B+Tree的磁碟結構 ## leaf磁碟結構 Freedom的B+Tree是儲存到磁盤裡的。考慮到儲存的限制以及不定長的key值,所以會變得非常複雜。Freedom以page為單位來和磁碟進行互動。葉子節點和非葉子節點都由page承載並刷入磁碟。結構如下所示: ![](https://oscimg.oschina.net/oscnet/up-abe84d1d9409b7c46b53447387c3b3069b7.png) 一個元組(tuple/item)在一個page中分為定長的ItemPointer和不定長的Item兩部分。 其中ItemPointer裡面儲存了對應item的起始偏移和長度。同時ItemPointer和Item如圖所示是向著中心方向進行伸張,這種結構很有效的組織了非定長Item。 ### leaf和node節點在Page中的不同 雖然leaf和node在page中組織結構一致,但其item包含的項確有區別。由於Freedom採用的是索引組織表,所以對於leaf在聚簇索引(clusterIndex)和二級索引(secondaryIndex)中對item的表示也有區別,如下圖所示: ![](https://oscimg.oschina.net/oscnet/up-d649ccfa767c9ba83998209dfea4d576fb8.png) 其中在二級索引搜尋時通過secondaryIndex通過index-key找到對應的clusterId,再通過 clusterId在clusterIndex中找到對應的row記錄。 由於要落盤,所以Freedom在node節點中的item裡面寫入了index-key對應的pageno, 這樣就可以容易的從磁碟恢復所有的索引結構了。 ### B+Tree在檔案中的組織 有了Page結構,我們就可以將資料承載在一個個page大小的記憶體裡面,同時還可以將page重新整理到對應的檔案裡。有了node.item中的pageno,我們就可以較容易的進行檔案和記憶體結構之間的互相映射了。 B+樹在磁碟檔案中的組織如下圖所示: ![](https://oscimg.oschina.net/oscnet/up-c1740d8e165978f46129c0f9115a4d997e8.png) B+樹在記憶體中相對應的對映結構如下圖所示: ![](https://oscimg.oschina.net/oscnet/up-cc89c3f7c515e6e572e8efb90d534372a0a.png) 檔案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如下圖所示: ![](https://oscimg.oschina.net/oscnet/up-62b37cd2e6d45c59ca4a5b2bf643f04a60d.png) 如果想讓mybatis可以自動生成關於Freedom的程式碼,還需實現一些特定的sql來展現Freedom的元資訊。這個在筆者另一個專案rider中有這樣的實現。原理如下圖所示: ![](https://oscimg.oschina.net/oscnet/up-11a9f315bd4b77683d3b7dffd105f8c8ce3.png) 實現了上述4類SQL之後,mybatis-generator就可以通過jdbc從Freedom獲取元資訊進而自動生成程式碼了。 ## 事務支援 由於當前Freedom並沒有保證併發,所以對於事務的支援只做了最簡單的WAL協議。通過記錄redo/undolog從而實現原子性。 ### redo/undo log協議格式 Freedom在每做一個修改操作時,都會生成一條日誌,其中記錄了修改前(undo)和修改後(redo)的行資訊,undo用來回滾,redo用來宕機recover。結構如下圖所示: ![](https://oscimg.oschina.net/oscnet/up-8672b50ccdf8ae795a07cff3dff33a674e2.png) ### WAL協議 WAL協議很好理解,就是在事務commit前將當前事務中所產生的的所有log記錄刷入磁碟。 Freedom自然也做了這個操作,使得可以在宕機後通過log恢復出所有的資料。 ![](https://oscimg.oschina.net/oscnet/up-83029d948723aea197e01beba17b26b1741.png) ### 回滾的實現 由於日誌中記錄了undo,所以對於一個事務的回滾直接通過日誌進行undo即可。如下圖所示: ![](https://oscimg.oschina.net/oscnet/up-b32f8511b08a172fb35bb8649f465501ac5.png) ### 宕機恢復 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的例子: ![](https://oscimg.oschina.net/oscnet/up-4a0c9b32a6cf09d157bb07f357261793d0a.JPEG) join查詢 ![](https://oscimg.oschina.net/oscnet/up-5f0ea6f33bfff904e8146d995319598c08d.JPEG) delete回滾 ![](https://oscimg.oschina.net/oscnet/up-34e77d656b9b19035e601133b150a2a6039.JPEG) ## Freedom todo Freedom還有很多工作沒有完成,例如有層次的鎖機制和MVCC等,由於工作忙起來就耽擱了。 於是筆者就看了看MySQL原始碼的實現理解了一下鎖和MVCC實現原理,並寫了兩篇部落格。比起 自己動手擼實在是輕鬆太多了^_^。 ### MVCC https://my.oschina.net/alchemystar/blog/1927425 ### 二階段鎖 https://my.oschina.net/alchemystar/blog/1438839 ## 尾聲 在造輪子的過程中一開始是非常有激情非常快樂的。但隨著系統越來越龐大,複雜性越來越高,進度就會越來越慢,還時不時要推翻自己原來的設想並重新設計,然後再協同修改關聯的所有程式碼,就如同泥沼,越陷越深。至此,筆者才領悟了軟體工程最重要的其實是控制複雜度!始終保持簡潔的介面和優雅的設計是實現一個大型系統的必要條件。 ## 收穫與遺憾 這次造輪子的過程基本滿足了筆者的初衷,通過寫一個數據庫來學習資料庫。不僅僅是加深了理解,最重要的是筆者在寫的過程中終於明白了資料庫為什麼要這麼設計,為什麼不那樣設計,僅僅對書本的閱讀可能並不會有這些思考與領悟。 當然,還是有很多遺憾的,Freedom並沒有實現鎖機制和MVCC。由於只能在工作閒暇時間寫,所以斷斷續續寫了一兩個月,工作一忙就將這個專案閒置了。現在將Freedom的設計寫出來,希望大家能有所收穫。 更多幹貨,盡在解Bug之路: ![image](https://oscimg.oschina.net/oscnet/up-03e8bdd592b3eb9dec0a50fa5ff56192df0.JPEG) ## github連結 https://github.com/alchemystar/Freedom