歡迎閱讀數據庫內核雜談的第一篇。今天我們摒棄直接介紹數據庫內核各個模塊的思路，而是從應用開發者的角度出發，來看實現一個數據庫需要哪些基本功能，然后把這些功能細分成最小的模塊再手把手一起實現，幫你揭開數據庫內核的神秘面紗。希望能夠減輕你對學習數據庫內核的壓力。我們也可以從中體會到，九層之臺，起于累土。所有復雜的系統，都是通過模塊化的架構和設計，以及工程階段的精益求精，一步一步累計起來。
對與應用開發者而言，一個數據庫需要哪些必要的功能呢？我覺得，下面這些是必不可少的：
1）創建數據庫和數據表：create database，schema, table等
2）存儲數據：insert /update數據，或者從其他方式導入數據(比如csv文件)
3）讀取查詢數據：通過SQL語句，對數據進行讀取和查詢，比如sort，aggregate，filter等
根據這三個功能，再回看標題，你可能產生疑問，一個小時就能實現上面這些功能，不會是標題黨吧。我承認，有一點小小得標題黨了。因為要和數據庫交互，最必要的條件是有個客戶端程序可以接受用戶送來的指令。但要實現一個功能齊全的Parser可得花不少精力。既然是內核雜談，請允許我偷個懶，假設Parser已經有實現，從而把精力都關注在數據庫系統內部的實現。拋開Parser，又該從哪開始呢？我的思路是跟著數據的流向，自下而上，依次從存儲數據，讀取數據和查詢數據來看。
創建和存儲數據
當用戶創建一個新的數據庫，并導入數據時，數據庫系統就需要存儲這些數據。說到存儲，第一個想法就是文件系統（其實說到底數據庫系統就是一個特殊的文件系統，區別與普通文件系統提供的的讀寫文件的接口，數據庫只是提供了一個面向數據的接口：存儲，讀取和查詢；整個系統為這些接口提供服務)。以下圖student表作為示例，要怎么把這張表存在文件中呢？
最顯而易見的就是用Comma-separated value(CSV)格式存:
1,"Xiaoputao",3,"Hiking"
2,"Zgu",3,"Running"
3,"Xiaopang",2,"Walking"
讀取CSV文件的邏輯也非常簡單: 一行一行讀取數據，然后根據";"把每個數據段取出。
除了CSV存儲，另一種常見的方式就是json格式:
[ {"id":1, "name":"Xiaoputao", "class":3, "hobby":"running}, ... ]
聊聊CSV和JSON存儲的優缺點。兩者都屬于文本存儲，優點一在于易于人類理解。另一個優點就是直接兼容其他支持CSV和JSON的數據庫。缺點也很明顯，存儲效率不高，讀取效率也會隨之降低。另一個問題在于，上述例子中存儲的內容只有值，沒有type和size(metadata)，這些信息在后續操作如校驗中是很重要的。當然，我們可以把metadata加入到存儲中，比如，把json的每個val變成一個obj:{"colName":"id","colType":"int","colSize":4,"colVal":1}。專業數據庫肯定不會選擇用CSV或JSON作為默認存儲，但幾乎都支持CSV和JSON數據作為external table。如果要追求更高的性能，我們可以選擇更高效的編碼方式把數據以字節流的形式存儲在文件中；只要數據庫系統自身能夠讀取這些數據即可。咱們既然時間有限，當然是一切從簡，就選擇CSV或者JSON的文件格式來存儲我們的數據。
只要有一個文本編輯器，能夠創建和編輯CSV或者JSON文件。這其實這已經完成了創建數據表，輸入，修改以及存儲數據的功能。
讀取數據
基于上述用CSV或JSON的存儲，讀取數據非常簡單(允許我們調用第三方支持CSV或者JSON的API)。重點在于讀取完存放在怎樣一個數據結構中方便后續對數據進一步的查詢操作。根據數據的特性，結果集(RowSet)是由一序列的行數據(Row)組成，每一行又由多個單元(Cell)組成。我們試著根據這個概念設計下面這些類：
簡單梳理下，每個Cell存type，size，和value；Row存一整行cell；RowSet存一序列的Row。具體在實現中還有很多細節需要注意，如typecheck, 確保每行列數相同，等等，這里也一并從簡略過。定義了存儲方式和數據結構，具體數據讀取代碼如下
csvToRowSet和jsonToRowSet的實現只需要借助第三方CSV和JSON的類庫就能實現，就不贅述代碼了。
這一節里，我們定義了Cell, Row, RowSet的數據結構來存放從文件(CSV或JSON)中讀取的數據，并給出了示例代碼。
執行查詢
有了存儲和讀取，已經可以把數據從文件中讀取到內存，接下來就要支持用戶的查詢語句了。實現查詢就是去實現SQL語句中的各個功能模塊，比如排序(order by), 聚合(group by)，多表聯合(join)等等。執行器會對每個功能模塊進行實現，甚至針對不同的數據分布，會有多種方式的實現來提高讀取速度。現在，我們一起來討論一些常用的語言功能。
全表讀取(SELECT *)
其實，定義了RowSet的數據結構和實現了讀取文件的接口，我們的數據庫就已經支持全表讀取的SQL語句，示例如下：
SELECT * FROM student;
分頁語句(LIMIT)
一下子就能想到的分頁語句，用來限制輸出的數據行數：
一行代碼，不解釋了。抬走！
關系映射語句(PROJECTION)
關系映射的本質是對于輸入的RowSet的每一行(row), 通過各種標量計算，輸出一個新的數據行，再由這些行組成新的RowSet。見下圖示例：
SELECT id + 5, LEN(name) FROM student;
對從student表讀取的每一行數據，輸出一個新的數據行包含 id + 5 和 LEN(name)的cells。
Projection可以非常復雜，但有一條準則就是它不改變原有RowSet的基數(cardinality), 即新RowSet的行數和原來的相同。因此，無論映射邏輯多復雜，輸入一個Row，輸出一個Row。再復雜的計算，也是一比一步迭代產生。比如上述示例可以分解成下面這些操作來完成：對于每一行input row, id值加5，對name取length，最后去掉class和hobby兩列。歸根結底就是將復雜的運算拆分成原子操作然后一步一步地順序執行。我們可以定義如下兩個基本operator：RowComputeOperator根據定義的computeCellVal對input row計算一個新cell，并把這個cell加到原row的末尾。SelectionOperator根據給定的indexes，生成一個僅包含指定index的新row。Pseudo code如下：
RowComputeOperator里面有需要定義computeCellVal，輸入是一個row,輸出一個新的cell。具體實現則根據具體語義來定。定義一個computeCellVal需要2個參數：1）運算作用在哪些cell上，假設限制只能作用在1個或2個cell上(2個以上可以用多個Operator嵌套)；2）提供具體計算的操作，比如常見單元操作如len(), ceiling(), abs()或者常見的二元操作如+-*/等等。
有了這兩個基本operator, 實現示例中的projection，我們定義3個operator即可：1）compute a new cell using "(id + 5)" 2) compute a new cell using "len(name)" 3) 用SelectionOperator選擇最后兩個新生成的cell。
實現整個projection的operator的pseudo code如下：
條件選擇語句(WHERE)
有了Projection，我們就可以實現下面的條件選擇語句(WHERE)了：
SELECT * FROM student WHERE?class = 3;
實現想法很簡單，首先用Projection operator計算出filter condition的值(bool)，然后filter by 這個cell即可。
排序語句(ORDER BY)
這里，我給一個非常低效但很容易理解的實現：創建一個hashmap來存<cell, id>，然后對要sort的cell排序，根據cell順序取出原row組成新的rowSet輸出：
有讀者會問，如果排序語句是一個expression而不是單個column怎么辦？比如下面的示例:
SELECT * FROM student ORDER BY id + 5 ASEC;
還記得我們前面實現的projection嗎？這里把(id + 5)作為一個新的projection加入到Row中即可。
一起實現了4個Operator，看看有沒有什么規律可循？所有定義的操作都是基于一個原則：輸入一個RowSet，然后輸出一個RowSet。并且，是一層一層循序漸進的迭代。對于數據的查詢操作，是從最初讀取表中的原始數據開始，根據給定的Operator序列對數據逐一進行操作；這一個Operator的輸出就是下一個operator的輸入。也就是說，給定一個SQL查詢語句，我們生成一序列Operator的tree，再依次執行，就能得到最終結果。現在來一起優化下代碼，把Operator的接口抽象出來，然后把剛才實現的operator全當成子類來實現。代碼如下：
有讀者會有疑問，基類為什么叫UnaryOperator呢？先賣個關子。有了基類，我們可以根據SQL的語法功能實現相應的Operator。
聚合操作(AGGREGATION)
接著一起來實現聚合操作。Aggregation分為兩大類，scalar-agg和multi-agg。scalar-agg就是簡單的sum, avg, min, max等的數據聚合操作，最終返回一個數據行的結果集，實現代碼如下：
每個AggOp接受一序列的cells，然后輸出聚合結果的cell。常見的AggOp如sum, max，min實現都很簡單，這邊就不贅述了。
multi-agg對應SQL中的GROUP By，如下圖示例：
SELECT class_room, COUNT(*) FROM student;
比scalar-agg復雜的地方就是先要把有相同值的group by columns(示例中為class_rom)的row合并起來，然后對合并后的rows做Scala-agg即可。代碼我就不貼啦，當留個小作業給大家。
SQL Operator Tree
有了實現基本語義的Operator，要實現一個完整的查詢語句，我們要做的就是把operator一層一層的累加起來，形成一個Operator tree，然后根據這個operator tree, 依次執行每一個operator即可。比如下面這個查詢語句：
select class, sum(id + len(name)) as c
from (
? ? select * from student where hobby = 'hiking' limit 10
)
group by class;
我們只要建立如下的Operator tree：
有沒有覺得挺神奇的！即使再復雜的查詢SQL都能這樣用基本的operator像搭樂高一樣搭建起來。
小結
至此，我們簡單的數據庫也實現得差不多啦。我看了下自己寫的pseudo code僅僅200多行，一個小時寫完也不算條件太苛刻。雖然數據結構冗余，算法低效，但是麻雀雖小，五臟俱全！
來解釋前面賣的關子，為什么基類定義為UnaryOperator？因為我們還有BinaryOperator。二元的操作是做什么的呢？答案就是為了表與表的聯合(join)。有了Binary Operator，Operator的疊加就真正變成了一顆樹(二叉樹)，這也是為什么前文我們稱之為operator tree。本文就先不詳述如何實現Join Operator了，以后會有專門的章節來覆蓋。再講下去，肯定超過一個小時，讀者就更覺得我標題黨了。
最后給大家總結一下：
1）一個SQL的查詢語句，即便邏輯再復雜，也可以拆分成一個一個原子operator的疊加
2）把這些operator組建成一個operator tree，然后自底向上地依次執行，就能得到最終的查詢結果
3) 你可能覺得真正的數據庫和我們在這搗鼓的很不一樣。如果有條件，可以在Mysql或者Postgres中運行"EXPLAIN SQL_STMT"來打印它們生成的operator tree，你會發現和我們生成的樹挺相似的
4) 相信大家都非常熟悉用SQL做各種數據查詢，但可能從沒去想過底層是怎樣實現的。希望這篇博客對你有所幫助。正所謂，知其然，知其所以然！
下一篇，咱們深入聊聊存儲!
