由一个bug引发的SQLite缓存一致性探索

时间:2021-05-31 08:36:49

问题

我们在生产环境中使用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句柄共享一个缓存区。其实问题很简单,但猜测复现问题还是花了一点精力。