问题
我们在生产环境中使用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句柄共享一个缓存区。其实问题很简单，但猜测复现问题还是花了一点精力。
----------✂-------------------------------------
如果您觉得文章不错，请点击右上角按钮分享到您的朋友圈！
点击阅读原文，访问北京测试空间IT实训基地微官网！
总结以上是内存溢出为你收集整理的由一个Bug引发的SQLite缓存一致性探索全部内容，希望文章能够帮你解决由一个Bug引发的SQLite缓存一致性探索所遇到的程序开发问题。
如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）