問(wèn)題

? ? ?我們?cè)谏a(chǎn)環(huán)境中使用SQLite時(shí)中發(fā)現(xiàn)建表報(bào)“table xxx already exists”錯(cuò)誤，但DB文件中并沒(méi)有該表。后面才發(fā)現(xiàn)這個(gè)是SQLite在實(shí)現(xiàn)過(guò)程中的一個(gè)bug，而這個(gè)bug與數(shù)據(jù)字典的一致性相關(guān)，下面這篇文章主要討論SQLite的緩存機(jī)制，以及緩存一致性實(shí)現(xiàn)的策略，希望對(duì)大家了解SQLite緩存機(jī)制有一定的幫助。

緩存

? ? ??SQLite中緩存主要包括兩方面，數(shù)據(jù)字典緩存和數(shù)據(jù)頁(yè)緩存。SQLite本身是一個(gè)文件數(shù)據(jù)庫(kù)，所有的數(shù)據(jù)都在一個(gè)DB文件中，文件以塊(page)的形式存放，默認(rèn)情況下每個(gè)page是1024個(gè)字節(jié)。為了避免每次訪問(wèn)都產(chǎn)生磁盤IO，針對(duì)數(shù)據(jù)塊在SQLite內(nèi)部實(shí)現(xiàn)了一層緩存
pagecache，pagecache的作用就是緩存頁(yè)數(shù)據(jù)。在SQLite內(nèi)部，除了用戶數(shù)據(jù)，還有一部分內(nèi)容是元數(shù)據(jù)信息，包括表，視圖，索引和觸發(fā)器等，這部分元數(shù)據(jù)信息在數(shù)據(jù)庫(kù)領(lǐng)域一般稱為數(shù)據(jù)字典，這部分信息也存在DB文件中。由于每次執(zhí)行語(yǔ)句時(shí)，都需要數(shù)據(jù)字典進(jìn)行語(yǔ)義分析和執(zhí)行計(jì)劃優(yōu)化(表是否存在，列是否存在，是否有索引可用，是否存在觸發(fā)器等)，如果每次獲取這些信息時(shí)，都需要從DB文件中獲取，則非常影響性能。你可能會(huì)說(shuō)，不是已經(jīng)有pagecache了嗎？對(duì)的，數(shù)據(jù)字典的內(nèi)容也緩存在pagecahce中，但是，要知道page中的數(shù)據(jù)都是二進(jìn)制的，需要對(duì)內(nèi)容進(jìn)行解析產(chǎn)生結(jié)構(gòu)化數(shù)據(jù)才能使用。為此，為了避免分析語(yǔ)句時(shí)，頻繁解析獲取數(shù)據(jù)字典，將解析好的數(shù)據(jù)進(jìn)行緩存，以供多次使用，提高效率。

數(shù)據(jù)頁(yè)緩存一致性
? ? ?我們這里討論的數(shù)據(jù)頁(yè)緩存對(duì)應(yīng)MySQL的概念就是BufferPool，當(dāng)然其它數(shù)據(jù)庫(kù)Oracle，SQLServer都有類似的概念。
傳統(tǒng)PC上面的數(shù)據(jù)庫(kù)，都是在數(shù)據(jù)庫(kù)服務(wù)啟動(dòng)時(shí)，根據(jù)參數(shù)設(shè)定值一次性分配特定大小的BufferPool。而SQLite采用懶分配策略，即“用多少則分配多少”，pagecache默認(rèn)大小是2000個(gè)page，2000個(gè)page可以認(rèn)為是一個(gè)緩存的上限。一次性分配的好處是，內(nèi)存在物理是連續(xù)的，不容易產(chǎn)生內(nèi)存碎片；而懶分配則更節(jié)約內(nèi)存，由于SQLite一般用于端設(shè)備，采用懶分配方式可能更經(jīng)濟(jì)實(shí)惠。SQLite的緩存分配策略采用LRU，保留最近訪問(wèn)的page，淘汰最老的page。
? ? ? SQLite中每個(gè)數(shù)據(jù)庫(kù)連接對(duì)應(yīng)一個(gè)DB句柄，應(yīng)用通過(guò)DB句柄來(lái)操作數(shù)據(jù)庫(kù)，而pagecache實(shí)際上就作為一個(gè)成員掛在DB句柄中，因此每個(gè)DB句柄都有自己獨(dú)立的緩存，這點(diǎn)與傳統(tǒng)的PC數(shù)據(jù)庫(kù)不同(比如MySQL中，所有連接共享BufferPool)。既然每個(gè)DB句柄有獨(dú)立的緩存，那么緩存之間如何同步？比如有Connection1和Connection2兩個(gè)連接，Connection1首先從文件中讀取了page_A并加入到了緩存；隨后Connection2也從文件中讀取Page_A，并進(jìn)行了更新；那么當(dāng)Connection1再次讀取page_A時(shí)，Connection1如何知道自己緩存的page_A已經(jīng)不是最新了，需要重新到DB文件中讀??？
SQLite為了處理這個(gè)問(wèn)題，在DB的文件控制頭中存放的DB的版本信息，開(kāi)始執(zhí)行SQL時(shí)會(huì)讀取DB的版本信息并緩存，如何發(fā)現(xiàn)本次的版本信息與之前的不同，則確認(rèn)DB文件已經(jīng)被修改，清理自身的緩存。每次事務(wù)提交時(shí)，都會(huì)調(diào)用pager_write_changecounter進(jìn)行更新，具體位置在第一頁(yè)的第24個(gè)字節(jié)，占4個(gè)字節(jié)。

數(shù)據(jù)字典緩存一致性
? ? ?我們這里討論的數(shù)據(jù)字典對(duì)應(yīng)MySQL的概念就是information_schema的系統(tǒng)表，字典緩存就是對(duì)系統(tǒng)表信息的結(jié)構(gòu)化信息存儲(chǔ)。在SQLite中字典信息采用Hash表存儲(chǔ)，包括(tblHash,idxHash,trigHash和fkeyHash等)判斷一個(gè)對(duì)象是否存在的依據(jù)是Hash表中對(duì)象是否存在。openDatabase函數(shù)通過(guò)調(diào)用sqlite3Init對(duì)數(shù)據(jù)字典進(jìn)行初始化，并設(shè)置標(biāo)記。與數(shù)據(jù)頁(yè)緩存一樣，字典緩存也是每個(gè)DB句柄有單獨(dú)的一份數(shù)據(jù)，同樣的，SQLite文件頭中同樣存放了數(shù)據(jù)字典的版本信息，具體位置在第一頁(yè)的第40個(gè)字節(jié)，占4個(gè)字節(jié)。進(jìn)行DDL操作時(shí)(CREATE,DROP,ALTER等)，會(huì)調(diào)用sqlite3ChangeCookie更新字典版本號(hào)(Schema cookie)。在Prepare階段分析語(yǔ)句時(shí)，若發(fā)現(xiàn)對(duì)象不存在，會(huì)觸發(fā)一次Schema cookie檢查，如果數(shù)據(jù)字典不是最新，則會(huì)調(diào)用sqlite3SchemaClear進(jìn)行清理，并重新加載數(shù)據(jù)字典。另外，SQLite的數(shù)據(jù)字典表非常簡(jiǎn)單，主要在sqlite_master表中，每個(gè)對(duì)象都是一行記錄，記錄中包含了表定義，加載字典時(shí)，實(shí)際就是將表定義語(yǔ)句分析一遍，通過(guò)調(diào)用sqlite3EndTable將對(duì)象加入Hash表，非常方便。

小結(jié)
? ? ?可以看到，無(wú)論數(shù)據(jù)頁(yè)緩存也好，數(shù)據(jù)字典緩存也好，SQLite都是采用一個(gè)版本號(hào)來(lái)控制版本信息，非常簡(jiǎn)單實(shí)用，但缺點(diǎn)是粒度非常大。如果DB寫非常頻繁，那么每次讀基本都會(huì)導(dǎo)致物理IO，可能修改的是A表，訪問(wèn)B表也需要將緩存清空。這里也可以解釋為什么頁(yè)緩存是“懶加載”模式，這樣清空緩存的代價(jià)也相對(duì)較小。對(duì)于數(shù)據(jù)字典緩存，粒度同樣很粗，每修改一個(gè)表，視圖，觸發(fā)器等對(duì)象，都會(huì)觸發(fā)數(shù)據(jù)字典版本更新。當(dāng)然SQLite不會(huì)傻傻的每次執(zhí)行SQL時(shí)都去判斷自己的版本是否最新，只是在訪問(wèn)對(duì)象時(shí)，對(duì)象不存在的情況才去檢查版本，這樣在一定程度上減少了加載的次數(shù)，但這樣也帶來(lái)了問(wèn)題，下面回到問(wèn)題本身。

回到問(wèn)題
? ? ?前面我們拋出了一個(gè)SQLite的bug，這里來(lái)細(xì)說(shuō)來(lái)龍去脈。假設(shè)有兩個(gè)DB句柄，分別稱為A和B。執(zhí)行如下序列： A：create table t(id int); B：DROP table if exists t; A: create table t(id int); 第二次A建表時(shí)會(huì)報(bào)“table t already exists”錯(cuò)誤，而實(shí)際上表已經(jīng)不存在了。這主要原因就是第3步A建表時(shí)發(fā)現(xiàn)表存在并沒(méi)有觸發(fā)去判斷數(shù)據(jù)字典是否最新的邏輯，導(dǎo)致誤報(bào)。復(fù)現(xiàn)該問(wèn)題時(shí)要注意關(guān)閉sharecache,因?yàn)樵趕harecache模式下，所有的DB句柄共享一個(gè)緩存區(qū)。其實(shí)問(wèn)題很簡(jiǎn)單，但猜測(cè)復(fù)現(xiàn)問(wèn)題還是花了一點(diǎn)精力。