SQLite 設計及概念

       1、API

　　由兩部分組成: 核心API(core API) 和擴展API（extension API）
　　核心API的函數實現基本的數據庫操作：連接數據庫，處理SQL，遍歷結果集。它也包括一些實用函數，比如字符串轉換，操作控制，調試和錯誤處理。
　　擴展API通過創建你自定義的SQL函數去擴展SQLite。

　　1.1、SQLite Version 3的一些新特點：
　　(1)SQLite的API全部重新設計，由第二版的15個函數增加到88個函數。這些函數包括支持UTF-8和UTF-16編碼的功能函數。
　　(2)改進併發性能。加鎖子系統引進一種鎖升級模型(lock escalation model)，解決了第二版的寫進程餓死的問題(該問題是任何一個DBMS必須面對的問題)。這種模型保證寫進程按照先來先服務的算法得到排斥鎖(Exclusive Lock)。甚至，寫進程通過把結果寫入臨時緩衝區(Temporary Buffer)，可以在得到排斥鎖之前就能開始工作。這對於寫要求較高的應用，性能可提高400%（引自參考文獻）。
　　(3)改進的B-樹。對於表採用B+樹，大大提高查詢效率。
       (4)SQLite 3最重要的改變是它的存儲模型。由第二版只支持文本模型，擴展到支持5種本地數據類型。
　　總之，SQLite Version 3與SQLite Vertion 2有很大的不同，在靈活性，特點和性能方面有很大的改進。

　　1.2、主要的數據結構(The Principal Data Structures)

　　SQLite由很多部分組成－parser,tokenize,virtual machine等等。但是從程序員的角度，最需要知道的是:connection, statements, B-tree和pager。它們之間的關係如下：

Java代碼：

        上圖告訴我們在編程需要知道的三個主要方面：API,事務(Transaction)和鎖(Locks)。從技術上來說，B-tree和pager不是API的一部分。但是它們卻在事務和鎖上起着關鍵作用。　

　

       1.3、Connections和Statements

　　Connection和statement是執行SQL命令涉及的兩個主要數據結構，幾乎所有通過API進行的操作都要用到它們。一個連接(Connection)代表在一個獨立的事務環境下的一個連接A (connection represents a single connection to a database as well as a single transaction context)。每一個statement都和一個connection關聯，它通常表示一個編譯過的SQL語句，在內部，它以VDBE字節碼錶示。Statement包括執行一個命令所需要一切，包括保存VDBE程序執行狀態所需的資源，指向硬盤記錄的B-樹遊標，以及參數等等。

　　1.4、B-tree和pager
　　一個connection可以有多個database對象---一個主要的數據庫以及附加的數據庫，每一個數據庫對象有一個B-tree對象，一個B-tree有一個pager對象(這裏的對象不是面向對象的“對象”，只是爲了說清楚問題)。
　　Statement最終都是通過connection的B-tree和pager從數據庫讀或者寫數據，通過B-tree的遊標(cursor)遍歷存儲在頁面(page)中的記錄。遊標在訪問頁面之前要把數所從disk加載到內存，而這就是pager的任務。任何時候，如果B-tree需要頁面，它都會請求pager從disk讀取數據，然後把頁面(page)加載到頁面緩衝區(page cache)，之後，B-tree和與之關聯的遊標就可以訪問位於page中的記錄了。
　　如果cursor改變了page，爲了防止事務回滾，pager必須採取特殊的方式保存原來的page。總的來說，pager負責讀寫數據庫，管理內存緩存和頁面（page），以及管理事務，鎖和崩潰恢復(這些在事務一節會詳細介紹)。
　　總之，關於connection和transaction，你必須知道兩件事：

　　(1)對數據庫的任何操作，一個連接存在於一個事務下。
　　(2)一個連接決不會同時存在多個事務下。
　　whenever a connection does anything with a database, it always operates under exactly one
　　transaction, no more, no less.

　　1.5、核心API
　　核心API 主要與執行SQL命令有關，本質上有兩種方法執行SQL語句：prepared query 和wrapped query。Prepared query由三個階段構成：preparation，execution和finalization。其實wrapped query只是對prepared query的三個過程包裝而已，最終也會轉化爲prepared query的執行。

　　1.5.1、連接的生命週期(The Connection Lifecycle)
　　和大多數據庫連接相同，由三個過程構成：
　　（1）連接數據庫(Connect to the database)：
　　每一個SQLite數據庫都存儲在單獨的操作系統文件中，連接，打開數據庫的C API爲：sqlite3_open()，它的實現位於main.c文件中，如下：
Java代碼：

1. int sqlite3_open(const char *zFilename, sqlite3 **ppDb){
   
2. return openDatabase(zFilename, ppDb, SQLITE_OPEN_READWRITE | SQLITE_OPEN_CREATE, 0);
   
3. }

複製代碼

　　當連接一個在磁盤上的數據庫，如果數據庫文件存在，SQLite打開一個文件；如果不存在，SQLite會假定你想創建一個新的數據庫。在這種情況下，SQLite不會立即在磁盤上創建一個文件，只有當你向數據庫寫入數據時纔會創建文件，比如：創建表、視圖或者其它數據庫對象。如果你打開一個數據，不做任何事，然後關閉它，SQLite會創建一個文件，只是一個空文件而已。
　　另外一個不立即創建一個新文件的原因是，一些數據庫的參數，比如：編碼，頁面大小等，只在在數據庫創建前設置。默認情況下，頁面大小爲1024字節，但是你可以選擇512-32768字節之間爲 2冪數的數字。有些時候，較大的頁面能更有效的處理大量的數據。
　　（2）執行事務(Perform transactions)：
　　all commands are executed within transactions。默認情況下，事務自動提交，也就是每一個SQL語句都在一個獨立的事務下運行。當然也可以通過使用BEGIN..COMMIT手動提交事務。
　　（3）斷開連接(Disconnect from the database)：
　　主要是關閉數據庫的文件。

　　1.5.2、執行Prepared Query
　　前面提到，預處理查詢(Prepared Query)是SQLite執行所有SQL命令的方式，包括以下三個過程：

　　(1)Prepared Query：
　　分析器（parser），分詞器(tokenizer)和代碼生成器(code generator)把SQL Statement編譯成VDBE字節碼，編譯器會創建一個statement句柄(sqlite3_stmt)，它包括字節碼以及其它執行命令和遍歷結果集的所有資源。
　　相應的C API爲sqlite3_prepare()，位於prepare.c文件中，如下：

Java代碼：

1. 
   
2. int sqlite3_prepare(
   
3. sqlite3 *db,　　　　　　　
   
4. const char *zSql,　　　　
   
5. int nBytes,　　　　　　　
   
6. sqlite3_stmt **ppStmt,　　
   
7. const char **pzTail　　　
   
8. ){
   
9. int rc;
   
10. rc = sqlite3LockAndPrepare(db,zSql,nBytes,0,ppStmt,pzTail);
    
11. assert( rc==SQLITE_OK || ppStmt==0 || *ppStmt==0 );　
    
12. return rc;
    
13. }
    
14. 
    

        (2)Execution：　　虛擬機執行字節碼，執行過程是一個步進(stepwise)的過程，每一步(step)由sqlite3_step()啓動，並由VDBE執行一段字節碼。由sqlite3_prepare編譯字節代碼，並由sqlite3_step()啓動虛擬機執行。在遍歷結果集的過程中，它返回SQLITE_ROW，當到達結果末尾時，返回SQLITE_DONE。

　　(3)Finalization：
　　VDBE關閉statement，釋放資源。相應的C API爲sqlite3_finalize()。
　　通過下圖可以更容易理解該過程：

Java代碼：

1. 
   
2. #include
   
3. #include
   
4. #include"sqlite3.h"
   
5. #include
   
6. intmain(intargc,char**argv){
   
7. int rc,i,ncols;
   
8. sqlite3 *db;
   
9. sqlite3_stmt *stmt;
   
10. char *sql;
    
11. const char*tail;
    
12. //打開數據
    
13. rc=sqlite3_open("foods.db",&db);
    
14. if(rc){
    
15. fprintf(stderr,"Can'topendatabase:%sn",sqlite3_errmsg(db));
    
16. sqlite3_close(db);
    
17. exit(1);
    
18. }
    
19. 　　
    
20. sql="select * from episodes";
    
21. //預處理
    
22. rc=sqlite3_prepare(db,sql,(int)strlen(sql),&stmt,&tail);
    
23. if(rc!=SQLITE_OK){
    
24. fprintf(stderr,"SQLerror:%sn",sqlite3_errmsg(db));
    
25. }
    
26. 　　
    
27. rc=sqlite3_step(stmt);
    
28. ncols=sqlite3_column_count(stmt);
    
29. while(rc==SQLITE_ROW){
    
30. 　　　　
    
31. for(i=0;ifprintf(stderr,"'%s'",sqlite3_column_text(stmt,i));
    
32. }
    
33. fprintf(stderr,"n");
    
34. rc=sqlite3_step(stmt);
    
35. }
    
36. //釋放statement
    
37. sqlite3_finalize(stmt);
    
38. //關閉數據庫
    
39. sqlite3_close(db);
    
40. return0;　　
    
41. }

本節討論事務,事務是DBMS最核心的技術之一.在計算機科學史上,有三位科學家因在數據庫領域的成就而獲ACM圖靈獎,而其中之一 Jim Gray(曾任職微軟)就是因爲在事務處理方面的成就而獲得這一殊榮,正是因爲他,才使得OLTP系統在隨後直到今天大行其道.關於事務處理技術,涉及到很多,隨便就能寫一本書.在這裏我只討論SQLite事務實現的一些原理,SQLite的事務實現與大型通用的DBMS相比,其實現比較簡單.這些內容可能比較偏於理論,但卻不難,也是理解其它內容的基礎.好了,下面開始第二節---事務.

       2、    事務(Transaction)

       2.1、事務的週期(Transaction Lifecycles)
       程序與事務之間有兩件事值得注意：
     （1）    哪些對象在事務下運行——這直接與API有關。
     （2）    事務的生命週期，即什麼時候開始，什麼時候結束以及它在什麼時候開始影響別的連接（這點對於併發性很重要）——這涉及到SQLite的具體實現。

       一個連接（connection）可以包含多個(statement)，而且每個連接有一個與數據庫關聯的B-tree和一個pager。Pager在連接中起着很重要的作用，因爲它管理事務、鎖、內存緩存以及負責崩潰恢復(crash recovery)。當你進行數據庫寫操作時，記住最重要的一件事：在任何時候，只在一個事務下執行一個連接。這些回答了第一個問題。
       一般來說，一個事務的生命和statement差不多，你也可以手動結束它。默認情況下，事務自動提交，當然你也可以通過BEGIN..COMMIT手動提交。接下來就是鎖的問題。

       2.2、鎖的狀態(Lock States)
       鎖對於實現併發訪問很重要，而對於大型通用的DBMS，鎖的實現也十分複雜，而SQLite相對較簡單。通常情況下，它的持續時間和事務一致。一個事務開始，它會先加鎖，事務結束，釋放鎖。但是系統在事務沒有結束的情況下崩潰，那麼下一個訪問數據庫的連接會處理這種情況。
       在SQLite中有5種不同狀態的鎖，連接（connection）任何時候都處於其中的一個狀態。下圖顯示了相應的狀態以及鎖的生命週期。

        關於這個圖有以下幾點值得注意：
      （1）    一個事務可以在UNLOCKED，RESERVED或EXCLUSIVE三種狀態下開始。默認情況下在UNLOCKED時開始。

      （2）    白色框中的UNLOCKED, PENDING, SHARED和 RESERVED可以在一個數據庫的同一時存在。
      （3）    從灰色的PENDING開始，事情就變得嚴格起來，意味着事務想得到排斥鎖(EXCLUSIVE)（注意與白色框中的區別）。
       雖然鎖有這麼多狀態，但是從體質上來說，只有兩種情況：讀事務和寫事務。

       2.3、讀事務(Read Transactions)
      我們先來看看SELECT語句執行時鎖的狀態變化過程，非常簡單：一個連接執行select語句，觸發一個事務，從UNLOCKED到SHARED，當事務COMMIT時，又回到UNLOCKED，就這麼簡單。

      考慮下面的例子(爲了簡單，這裏用了僞碼)：

Java代碼：

1. db = open('foods.db')
   
2. db.exec('BEGIN')
   
3. db.exec('SELECT * FROM episodes')
   
4. db.exec('SELECT * FROM episodes')
   
5. db.exec('COMMIT')
   
6. db.close()
   

      由於顯式的使用了BEGIN和COMMIT，兩個SELECT命令在一個事務下執行。第一個exec()執行時，connection處於SHARED，然後第二個exec()執行，當事務提交時，connection又從SHARED回到UNLOCKED狀態，如下：

Java代碼：

1. UNLOCKED→PENDING→SHARED→UNLOCKED
   
2. //如果沒有BEGIN和COMMIT兩行時如下：
   
3. UNLOCKED→PENDING→SHARED→UNLOCKED→PENDING→ SHARED→UNLOCKED
   

       2.4、寫事務（Write Transactions）
       下面我們來考慮寫數據庫，比如UPDATE。和讀事務一樣，它也會經歷UNLOCKED→PENDING→SHARED，但接下來卻是灰色的PENDING，

       2.4.1、The Reserved States
       當一個連接（connection）向數據庫寫數據時，從SHARED狀態變爲RESERVED狀態，如果它得到RESERVED鎖，也就意味着它已經準備好進行寫操作了。即使它沒有把修改寫入數據庫，也可以把修改保存到位於pager中緩存中（page cache）。
       當一個連接進入RESERVED狀態，pager就開始初始化恢復日誌（rollback journal）。在RESERVED狀態下，pager管理着三種頁面：

       (1)    Modified pages：包含被B-樹修改的記錄，位於page cache中。
       (2)    Unmodified pages：包含沒有被B-tree修改的記錄。
       (3)    Journal pages：這是修改頁面以前的版本，這些並不存儲在page cache中，而是在B-tree修改頁面之前寫入日誌。
       Page cache非常重要，正是因爲它的存在，一個處於RESERVED狀態的連接可以真正的開始工作，而不會干擾其它的（讀）連接。所以，SQLite可以高效的處理在同一時刻的多個讀連接和一個寫連接。

        2.4.2 、The Pending States
        當一個連接完成修改，就真正開始提交事務，執行該過程的pager進入EXCLUSIVE狀態。從RESERVED狀態，pager試着獲取 PENDING鎖，一旦得到，就獨佔它，不允許任何其它連接獲得PENDING鎖（PENDING is a gateway lock）。既然寫操作持有PENDING鎖，其它任何連接都不能從UNLOCKED狀態進入SHARED狀態，即沒有任何連接可以進入數據（no new readers, no new writers）。只有那些已經處於SHARED狀態的連接可以繼續工作。而處於PENDING狀態的Writer會一直等到所有這些連接釋放它們的鎖，然後對數據庫加EXCUSIVE鎖，進入EXCLUSIVE狀態，獨佔數據庫(討論到這裏，對SQLite的加鎖機制應該比較清晰了)。

        2.4.3、The Exclusive State
        在EXCLUSIVE狀態下，主要的工作是把修改的頁面從page cache寫入數據庫文件，這是真正進行寫操作的地方。在pager寫入modified pages之前，它還得先做一件事：寫日誌。它檢查是否所有的日誌都寫入了磁盤，而這些通常位於操作的緩衝區中，所以pager得告訴OS把所有的文件寫入磁盤，這是由程序synchronous(通過調用OS的相應的API實現)完成的。
       日誌是數據庫進行恢復的惟一方法，所以日誌對於DBMS非常重要。如果日誌頁面沒有完全寫入磁盤而發生崩潰，數據庫就不能恢復到它原來的狀態，此時數據庫就處於不一致狀態。日誌寫入完成後，pager就把所有的modified pages寫入數據庫文件。接下來就取決於事務提交的模式，如果是自動提交，那麼pager清理日誌，page cache，然後由EXCLUSIVE進入UNLOCKED。如果是手動提交，那麼pager繼續持有EXCLUSIVE鎖和保存日誌，直到COMMIT 或者ROLLBACK。

       總之，從性能方面來說，進程佔有排斥鎖的時間應該儘可能的短，所以DBMS通常都是在真正寫文件時纔會佔有排斥鎖，這樣能大大提高併發性能。

轉自：http://www.eoeandroid.com/thread-71727-1-1.html