由一個bug引發的SQLite緩衝一致性探索

標籤：

問題

     我們在生產環境中使用SQLite時中發現建表報“table xxx already exists”錯誤，但DB檔案中並沒有該表。後面才發現這個是SQLite在實現過程中的一個bug，而這個bug與資料字典的一致性相關，下面這篇文章主要討論SQLite的緩衝機制，以及緩衝一致性實現的策略，希望對大家瞭解SQLite緩衝機制有一定的協助。

緩衝

      SQLite中緩衝主要包括兩方面，資料字典緩衝和資料頁緩衝。SQLite本身是一個檔案資料庫，所有的資料都在一個DB檔案中，檔案以塊(page)的形式存放，預設情況下每個page是1024個位元組。為了避免每次訪問都產生磁碟IO，針對資料區塊在SQLite內部實現了一層緩衝
pagecache，pagecache的作用就是快取頁面資料。在SQLite內部，除了使用者資料，還有一部分內容是中繼資料資訊，包括表，視圖，索引和觸發器等，這部分中繼資料資訊在資料庫領域一般稱為資料字典，這部分資訊也存在DB檔案中。由於每次執行語句時，都需要資料字典進行語義分析和執行計畫最佳化(表是否存在，列是否存在，是否有索引可用，是否存在觸發器等)，如果每次擷取這些資訊時，都需要從DB檔案中擷取，則非常影響效能。你可能會說，不是已經有pagecache了嗎？對的，資料字典的內容也緩衝在pagecahce中，但是，要知道page中的資料都是二進位的，需要對內容進行解析產生結構化資料才能使用。為此，為了避免分析語句時，頻繁解析擷取資料字典，將解析好的資料進行緩衝，以供多次使用，提高效率。

資料頁緩衝一致性
     我們這裡討論的資料頁緩衝對應MySQL的概念就是BufferPool，當然其它資料庫Oracle，SQLServer都有類似的概念。
傳統PC上面的資料庫，都是在資料庫服務啟動時，根據參數設定值一次性分配特定大小的BufferPool。而SQLite採用懶分配策略，即“用多少則分配多少”，pagecache預設大小是2000個page，2000個page可以認為是一個緩衝的上限。一次性分配的好處是，記憶體在物理是連續的，不容易產生記憶體片段；而懶分配則更節約記憶體，由於SQLite一般用於端裝置，採用懶分配方式可能更經濟實惠。SQLite的緩衝分配策略採用LRU，保留最近訪問的page，淘汰最老的page。
      SQLite中每個資料庫連接對應一個DB控制代碼，應用通過DB控制代碼來操作資料庫，而pagecache實際上就作為一個成員掛在DB控制代碼中，因此每個DB控制代碼都有自己獨立的緩衝，這點與傳統的PC資料庫不同(比如MySQL中，所有串連共用BufferPool)。既然每個DB控制代碼有獨立的緩衝，那麼緩衝之間如何同步？比如有Connection1和Connection2兩個串連，Connection1首先從檔案中讀取了page_A並加入到了緩衝；隨後Connection2也從檔案中讀取Page_A，並進行了更新；那麼當Connection1再次讀取page_A時，Connection1如何知道自己緩衝的page_A已經不是最新了，需要重新到DB檔案中讀取？
SQLite為了處理這個問題，在DB的檔案控制頭中存放的DB的版本資訊，開始執行SQL時會讀取DB的版本資訊並緩衝，如何發現本次的版本資訊與之前的不同，則確認DB檔案已經被修改，清理自身的緩衝。每次事務提交時，都會調用pager_write_changecounter進行更新，具體位置在第一頁的第24個位元組，佔4個位元組。

資料字典緩衝一致性
     我們這裡討論的資料字典對應MySQL的概念就是information_schema的系統資料表，字典緩衝就是對系統資料表資訊的結構化資訊儲存。在SQLite中字典資訊採用Hash表格儲存體，包括(tblHash,idxHash,trigHash和fkeyHash等)判斷一個對象是否存在的依據是Hash表中對象是否存在。openDatabase函數通過調用sqlite3Init對資料字典進行初始化，並設定標記。與資料頁緩衝一樣，字典緩衝也是每個DB控制代碼有單獨的一份資料，同樣的，SQLite檔案頭中同樣存放了資料字典的版本資訊，具體位置在第一頁的第40個位元組，佔4個位元組。進行DDL操作時(CREATE,DROP,ALTER等)，會調用sqlite3ChangeCookie更新字典版本號碼(Schema cookie)。在Prepare階段分析語句時，若發現對象不存在，會觸發一次Schema cookie檢查，如果資料字典不是最新，則會調用sqlite3SchemaClear進行清理，並重新載入資料字典。另外，SQLite的資料字典表非常簡單，主要在sqlite_master表中，每個對象都是一行記錄，記錄中包含了表定義，載入字典時，實際就是將表定義語句分析一遍，通過調用sqlite3EndTable將對象加入Hash表，非常方便。

小結
     可以看到，無論資料頁緩衝也好，資料字典緩衝也好，SQLite都是採用一個版本號碼來控製版本資訊，非常簡單實用，但缺點是粒度非常大。如果DB寫非常頻繁，那麼每次讀基本都會導致物理IO，可能修改的是A表，訪問B表也需要將緩衝清空。這裡也可以解釋為什麼頁緩衝是“懶載入”模式，這樣清空緩衝的代價也相對較小。對於資料字典緩衝，粒度同樣很粗，每修改一個表，視圖，觸發器等對象，都會觸發資料字典版本更新。當然SQLite不會傻傻的每次執行SQL時都去判斷自己的版本是否最新，只是在訪問對象時，對象不存在的情況才去檢查版本，這樣在一定程度上減少了載入的次數，但這樣也帶來了問題，下面回到問題本身。

回到問題
     前面我們拋出了一個SQLite的bug，這裡來細說來龍去脈。假設有兩個DB控制代碼，分別稱為A和B。執行如下序列： A：create table t(id int); B：DROP table if exists t; A: create table t(id int); 第二次A建表時會報“table t already exists”錯誤，而實際上表已經不存在了。這主要原因就是第3步A建表時發現表存在並沒有觸發去判斷資料字典是否最新的邏輯，導致誤判。複現該問題時要注意關閉sharecache,因為在sharecache模式下，所有的DB控制代碼共用一個緩衝區。其實問題很簡單，但猜測複現問題還是花了一點精力。

 

由一個bug引發的SQLite緩衝一致性探索