淺談SQLite——實現與應用

1、前言

有一些日子沒有仔細關注SQLite了，今天開啟其首頁，發現其最新的版本已經是3.6.22了，更讓我驚喜的是它的使用者越來越多，而且郵件清單的粉絲也越來越多，突然覺得自己已經太old了。驚喜的同時，不得不聊上幾句了。

首先，來看看都有哪些人在使用SQLite，首頁上列舉一長串NB的使用者，其中不乏像Adobe，Apple，Firefox，甚至連google，Microsoft，SUN這樣的使用者。

Firefox：這是我的機器上V3.5.7安裝目錄下的檔案：

 

可以發現用的SQLite 3.6.16.1。

據說，Google在它的Desktop for Mac，Google Gears，以及Android，甚至Chrome中都用到SQLite，而且，Google的工程師對SQLite的全文檢索索引功能作了很大的貢獻(contribution)。還有Apple，Micorsoft，SUN等等，這裡就不列舉了。詳細見http://www.sqlite.org/famous.html。有這些公司的參與，對SQLite的發展應該有很大的協助，尤其是像Google這樣的使用者。

 

2、實現與應用

下面從實現及應用的角度來談談SQLite，先看看SQLite的特點(功能)吧。

特點

簡單(simple)：SQLite是一個非常輕量級自包含(lightweight and self-contained)的DBMS：一個標頭檔，一個動態庫檔案，你就擁有了關聯式資料庫的所有功能了。簡單，是SQLite最明顯的哲學。它提供的API少而簡單。只需要一個DLL檔案，你的程式馬上就擁有了一個功能強大的資料庫引擎，這是一件很美妙的事。

小巧(small)：我用VS 2005在Windows下編譯的3.6.11，Release版為368K，用時不到20秒——而編譯MySQL時，要花上幾分鐘。而當我插入10000條int資料時，記憶體開銷660K，磁碟開銷92K。

事務(transaction)：事務是現代商業資料處理系統最基本的要求，而Access，不論是在可執行檔大小（看了一下Access2003的可執行檔大小為6.32M，兩者不是一個量級），還是事務特性，都是不能和SQLite 相比的。

並發性(Concurrency)：由於SQLite通過OS的檔案鎖來實現庫級鎖，粒度很大，但是，它通過一些複雜特殊的處理(具體可以參見分析系列)，盡量的提升了讀寫的並發度。如果你還有擔心，你可以看看這篇文章：http://www.dbanotes.net/database/sqlite_cms.html。

SQL92：SQLite支援絕大部分的標準SQL語句，你只需要幾百K的空間，就可以換來需要上百兆的通用DBMS幾乎所有操作了。

方便(Convenience)：如果你的程式要使用SQLite，只需要將拷貝你的程式目錄即可。

開源(Opensource)：這是它最強大的地方。開源，意味著你可以品讀它的源碼，你可以隨時修改它，加入你自己的特性，而這一切完全免費的。開源，是一種精神。

 

實現部分

好了，現在從實現的角度來談談個人體會，這也是我比較關注的。

SQLite是一款優秀的嵌入式資料庫管理系統，這裡有兩層含義：一是它經常作為動態庫嵌入到應用程式；另外一方面它通常用於嵌入式裝置或其它要求較低的案頭應用。如果把它作為記憶體資料庫，個人覺得不是很適合。畢竟，它的寫並發性不是很好，此時， TimesTen也許會更好，Berkey DB也許是一個不錯的選擇。SQLite這樣的嵌入式資料庫與主存資料庫的應用情境、實現以及對資源的需求都是不一樣的。

(1)交易處理

事務的核心問題有兩個：並發控制和恢複。解決了並發控制和恢複問題的系統，就能允許它的使用者假設程式是原子的(atomically)執行的——好像沒有其它的程式同時執行；而且是可靠的(reliably)——不會產生失敗。原子性和可靠性的抽象，則稱為事務(transaction)。其實，事務並不是DBMS的專利，任何分布式系統，都面對並發和恢複問題，而解決的方法就是事務，只不過，我們更常聽到DBMS中的事務。

並發控制保證事務的原子執行，它使得交錯執行的事務看起來是一個接一個的順序執行的，完全沒有交錯執行。如果交錯執行的結果與順序執行的結果一致，則稱為序列化(serializable)。

恢複使得資料庫僅僅包含那些正常完成的事務的結果。如果事務在執行的過程中發生錯誤，不能繼續進行，恢複演算法必須清除部分完成事務產生的影響。

• 並發控制

SQLite只支援庫級鎖，庫級鎖意味著什嗎？——意味著同時只能允許一個寫操作，也就是說，即事務T1在A表插入一條資料，事務T2在B表中插入一條資料，這兩個操作不能同時進行，即使你的機器有100個CPU，也無法同時進行，而只能順序進行。表級都不能並行，更別說元組級了——這就是庫級鎖。但是，SQLite盡量延遲申請X鎖，直到資料區塊真正寫盤時才申請X鎖，這是非常巧妙而有效。

• 恢複

SQLite的恢複技術是影子分頁技術(shadow paging)技術的典型代表。

DBMS的常用恢複技術有影子分頁技術與基於日誌的技術，前者在早其資料庫管理系統中用到，比如System R，現代DBMS中已經很難見到它的身影了。

影子分頁技術與基於日誌技術相比，優點是實現簡單，消除了寫日誌記錄的開銷，恢複的速度也快(不需要redo和undo)。影子分頁的缺點就是事務提交時要輸出多個塊，這使得提交的開銷很大，而且以塊為單位，很難應用到允許多個事務並發執行的情況——這是它致命的缺點。

(2)查詢處理

SQLite的查詢處理本質上就是一個SQL編譯器和一個虛擬機器。而實現這些功能只用了十多個檔案，整個實現實現簡單而有效，但是也存在一些問題。首先，SQLite字典資料很簡單，實際上它的字典就一個表sqlite_mater，所有的資訊都是通過對sqlite_master中SQL語句進行解析擷取的，而解析一個SQL語句，都需要進行詞法分析、文法分析、甚至虛擬機器代碼的產生。而這一過程是很需要時間的，而且，查詢計劃也沒有重用。其次，查詢最佳化還比較簡單，特別是串連操作，只通過迴圈來做(MySQL也一樣)。但是，僅僅數萬代碼，我們不能對它要求太苛求。

(3)儲存模型

SQLite的檔案物理上被劃分成相同大小的塊；邏輯上劃分成一些B-Tree——每個表對應一個B-Tree。而沒有像Oracle，或者InnoDB對資料區塊進行複雜的邏輯組織，這種按需分配資料區塊的做法必然影響磁碟的讀寫效能。不過，歸根到底，還是源於它的應用情境。

(4)緩衝區管理

Buffer的管理對於DBMS，無疑是非常重要的，SQLite在其它方面做得比較簡單，但是在緩衝區管理這一塊，它還是做足了功夫。SQLite採用DBMS常用的LRU演算法。更值得一提的是，在較新的版本中，SQLite採用和虛擬檔案系統的類似的方式，實現了讓預設緩衝區管理子系統可以很容易的切換成其它的緩衝區管理演算法，這是非常靈活的。

(5)I/O

SQLite採用簡單的阻塞I/O，較新的版本將非同步I/O作為可選的擴充，但是，由於SQLite沒有日誌，所以，事務中ACID中的D，就無法保證，所以，如果你的資料很關鍵，請不要用SQLite的非同步I/O。另一方面，實際上，很多嵌入式作業系統，比如Windows CE並不支援非同步I/O(不過，這可以通過多線程加以解決)。

但是，這些“缺點”並不是SQLite的缺點，相對於通過DBMS，恰恰是它的優點，這樣的實現簡單，而且對資源的需求較低。對嵌入式裝置、或者那些要求較低的應用，已經足夠，足夠就好。

 

應用情境

嵌入式裝置：這應該是SQLite應用的主要情境，很多公司都在他們的嵌入式應用程式中使用SQLite，其中不乏google的Android。

案頭應用：如果你已經厭惡了fopen，fread，fwrite這些函數，SQLite是你不錯的選擇，它介面簡單，而且支援事務。前些天無意中下了一個cookie清除軟體——CookieCrumbler，開啟一看，發現裡面竟然有一個sqlite3.dll，著實讓我震驚了一把。

Websites：如果你的網站的訪問量、資料量小的個人網站，SQLite可以代替開銷較大的MySQL和繁雜的Access。

 

後記

SQLite正在不斷髮展，開源的力量是巨大的，相信它的應用會越來越廣泛。Wish~