SQLite入门与分析转.docx
- 文档编号:7767079
- 上传时间:2023-01-26
- 格式:DOCX
- 页数:72
- 大小:408.29KB
SQLite入门与分析转.docx
《SQLite入门与分析转.docx》由会员分享,可在线阅读,更多相关《SQLite入门与分析转.docx(72页珍藏版)》请在冰豆网上搜索。
SQLite入门与分析转
SQLite入门与分析
2011/8/29
2011/9/1
出于项目的需要,最近打算对SQLite的内核进行一个完整的剖析,在此希望和对SQLite有兴趣的一起交流。
我知道,这是一个漫长的过程,就像曾经去读Linux内核一样,这个过程也将是辛苦的,但我相信结果一定是美好的......接下来是第一章。
一、SQLite介绍
自几十年前出现的商业应用程序以来,数据库就成为软件应用程序的主要组成部分。
正与数据库管理系统非常关键一样,它们也变得非常庞大,并占用了相当多的系统资源,增加了管理的复杂性。
随着软件应用程序逐渐模块模块化,一种新型数据库会比大型复杂的传统数据库管理系统更适应。
嵌入式数据库直接在应用程序进程中运行,提供了零配置(zero-configuration)运行模式,并且资源占用非常少。
SQLite是一个开源的嵌入式关系数据库,它在2000年由D.RichardHipp发布,它的减少应用程序管理数据的开销,SQLite可移植性好,很容易使用,很小,高效而且可靠。
SQLite嵌入到使用它的应用程序中,它们共用相同的进程空间,而不是单独的一个进程。
从外部看,它并不像一个RDBMS(关系型数据库系统),但在进程内部,它却是完整的,自包含的数据库引擎。
嵌入式数据库的一大好处就是在你的程序内部不需要网络配置,也不需要管理。
因为客户端和服务器在同一进程空间运行。
SQLite的数据库权限只依赖于文件系统,没有用户帐户的概念。
SQLite有数据库级锁定,没有网络服务器。
它需要的内存,其它开销很小,适合用于嵌入式设备。
你需要做的仅仅是把它正确的编译到你的程序。
二、架构(architecture)
SQLite采用了模块的设计,它由三个子系统,包括8个独立的模块构成。
2.1、接口(Interface)
接口由SQLiteCAPI组成,也就是说不管是程序、脚本语言还是库文件,最终都是通过它与SQLite交互的(我们通常用得较多的ODBC/JDBC最后也会转化为相应CAPI的调用)。
2.2、编译器(Compiler)
在编译器中,分词器(Tokenizer)和分析器(Parser)对SQL进行语法检查,然后把它转化为底层能更方便处理的分层的数据结构---语法树,然后把语法树传给代码生成器(codegenerator)进行处理。
而代码生成器根据它生成一种针对SQLite的汇编代码,最后由虚拟机(VirtualMachine)执行。
2.3、虚拟机(VirtualMachine)
架构中最核心的部分是虚拟机,或者叫做虚拟数据库引擎(VirtualDatabaseEngine,VDBE)。
它和Java虚拟机相似,解释执行字节代码。
VDBE的字节代码由128个操作码(opcodes)构成,它们主要集中在数据库操作。
它的每一条指令都用来完成特定的数据库操作(比如打开一个表的游标)或者为这些操作栈空间的准备(比如压入参数)。
总之,所有的这些指令都是为了满足SQL命令的要求(关于VM,后面会做详细介绍)。
2.4、后端(Back-End)
后端由B-树(B-tree),页缓存(pagecache,pager)和操作系统接口(即系统调用)构成。
B-tree和pagecache共同对数据进行管理。
B-tree的主要功能就是索引,它维护着各个页面之间的复杂的关系,便于快速找到所需数据。
而pager的主要作用就是通过OS接口在B-tree和Disk之间传递页面。
三、SQLite的特点(SQLite’sFeaturesandPhilosophy)
3.1、零配置(ZeroConfiguration)
3.2、可移植(Portability):
它是运行在Windows,Linux,BSD,MacOSX和一些商用Unix系统,比如Sun的Solaris,IBM的AIX,同样,它也可以工作在许多嵌入式操作系统下,比如QNX,VxWorks,PalmOS,Symbin和WindowsCE。
3.3、Compactness:
SQLite是被设计成轻量级,自包含的。
oneheaderfile,onelibrary,andyou’rerelational,noexternaldatabaseserverrequired
3.4、简单(Simplicity)
3.5、灵活(Flexibility)
3.6、可靠(Reliability):
SQLite的核心大约有3万行标准C代码,这些代码都是模块化的,很容易阅读。
主要参考:
TheDefinitiveGuidetoSQLite
四、设计与概念
我原打算直接从VDBE入手的,因为它起着承上启下的作用,是整个SQLite的核心,并分析源码,但考虑到这是一个系列的文章,我希望能把问题说全,所以还是从基本概念入手,对于初学者,如果没有这些概念,是很继续下去的。
好了,下面开始第二章,由于这一章内容很多,我将分两部分讨论,下面开始第一部分。
1、API
由两部分组成:
核心API(coreAPI)和扩展API(extensionAPI)
核心API的函数实现基本的数据库操作:
连接数据库,处理SQL,遍历结果集。
它也包括一些实用函数,比如字符串转换,操作控制,调试和错误处理。
扩展API通过创建你自定义的SQL函数去扩展SQLite。
1.1、SQLiteVersion3的一些新特点:
(1)SQLite的API全部重新设计,由第二版的15个函数增加到88个函数。
这些函数包括支持UTF-8和UTF-16编码的功能函数。
(2)改进并发性能。
加锁子系统引进一种锁升级模型(lockescalationmodel),解决了第二版的写进程饿死的问题(该问题是任何一个DBMS必须面对的问题)。
这种模型保证写进程按照先来先服务的算法得到排斥锁(ExclusiveLock)。
甚至,写进程通过把结果写入临时缓冲区(TemporaryBuffer),可以在得到排斥锁之前就能开始工作。
这对于写要求较高的应用,性能可提高400%(引自参考文献)。
(3)改进的B-树。
对于表采用B+树,大大提高查询效率。
(4)SQLite3最重要的改变是它的存储模型。
由第二版只支持文本模型,扩展到支持5种本地数据类型。
总之,SQLiteVersion3与SQLiteVertion2有很大的不同,在灵活性,特点和性能方面有很大的改进。
1.2、主要的数据结构(ThePrincipalDataStructures)
SQLite由很多部分组成-parser,tokenize,virtualmachine等等。
但是从程序员的角度,最需要知道的是:
connection,statements,B-tree和pager。
它们之间的关系如下:
上图告诉我们在编程需要知道的三个主要方面:
API,事务(Transaction)和锁(Locks)。
从技术上来说,B-tree和pager不是API的一部分。
但是它们却在事务和锁上起着关键作用(稍后将讨论)。
1.3、Connections和Statements
Connection和statement是执行SQL命令涉及的两个主要数据结构,几乎所有通过API进行的操作都要用到它们。
一个连接(Connection)代表在一个独立的事务环境下的一个连接A(connectionrepresentsasingleconnectiontoadatabaseaswellasasingletransactioncontext)。
每一个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)加载到页面缓冲区(pagecache),之后,B-tree和与之关联的游标就可以访问位于page中的记录了。
如果cursor改变了page,为了防止事务回滚,pager必须采取特殊的方式保存原来的page。
总的来说,pager负责读写数据库,管理内存缓存和页面(page),以及管理事务,锁和崩溃恢复(这些在事务一节会详细介绍)。
总之,关于connection和transaction,你必须知道两件事:
(1)对数据库的任何操作,一个连接存在于一个事务下。
(2)一个连接决不会同时存在多个事务下。
wheneveraconnectiondoesanythingwithadatabase,italwaysoperatesunderexactlyone
transaction,nomore,noless.
1.5、核心API
核心API主要与执行SQL命令有关,本质上有两种方法执行SQL语句:
preparedquery和wrappedquery。
Preparedquery由三个阶段构成:
preparation,execution和finalization。
其实wrappedquery只是对preparedquery的三个过程包装而已,最终也会转化为preparedquery的执行。
1.5.1、连接的生命周期(TheConnectionLifecycle)
和大多数据库连接相同,由三个过程构成:
(1)连接数据库(Connecttothedatabase):
每一个SQLite数据库都存储在单独的操作系统文件中,连接,打开数据库的CAPI为:
sqlite3_open(),它的实现位于main.c文件中,如下:
intsqlite3_open(constchar*zFilename,sqlite3**ppDb)
{
returnopenDatabase(zFilename,ppDb,SQLITE_OPEN_READWRITE|SQLITE_OPEN_CREATE,0);
}
当连接一个在磁盘上的数据库,如果数据库文件存在,SQLite打开一个文件;如果不存在,SQLite会假定你想创建一个新的数据库。
在这种情况下,SQLite不会立即在磁盘上创建一个文件,只有当你向数据库写入数据时才会创建文件,比如:
创建表、视图或者其它数据库对象。
如果你打开一个数据,不做任何事,然后关闭它,SQLite会创建一个文件,只是一个空文件而已。
另外一个不立即创建一个新文件的原因是,一些数据库的参数,比如:
编码,页面大小等,只在在数据库创建前设置。
默认情况下,页面大小为1024字节,但是你可以选择512-32768字节之间为2幂数的数字。
有些时候,较大的页面能更有效的处理大量的数据。
(2)执行事务(Performtransactions):
allcommandsareexecutedwithintransactions。
默认情况下,事务自动提交,也就是每一个SQL语句都在一个独立的事务下运行。
当然也可以通过使用BEGIN..COMMIT手动提交事务。
(3)断开连接(Disconnectfromthedatabase):
主要是关闭数据库的文件。
1.5.2、执行PreparedQuery
前面提到,预处理查询(PreparedQuery)是SQLite执行所有SQL命令的方式,包括以下三个过程:
(1)PreparedQuery:
分析器(parser),分词器(tokenizer)和代码生成器(codegenerator)把SQLStatement编译成VDBE字节码,编译器会创建一个statement句柄(sqlite3_stmt),它包括字节码以及其它执行命令和遍历结果集的所有资源。
相应的CAPI为sqlite3_prepare(),位于prepare.c文件中,如下:
intsqlite3_prepare(
sqlite3*db,
constchar*zSql,
intnBytes,
sqlite3_stmt**ppStmt,
constchar**pzTail
){
intrc;
rc=sqlite3LockAndPrepare(db,zSql,nBytes,0,ppStmt,pzTail);
assert(rc==SQLITE_OK||ppStmt==0||*ppStmt==0);
returnrc;
}
(2)Execution:
虚拟机执行字节码,执行过程是一个步进(stepwise)的过程,每一步(step)由sqlite3_step()启动,并由VDBE执行一段字节码。
由sqlite3_prepare编译字节代码,并由sqlite3_step()启动虚拟机执行。
在遍历结果集的过程中,它返回SQLITE_ROW,当到达结果末尾时,返回SQLITE_DONE。
(3)Finalization:
VDBE关闭statement,释放资源。
相应的CAPI为sqlite3_finalize()。
通过下图可以更容易理解该过程:
最后以一个具体的例子结束本节,下节讨论事务。
#include
#include
#include"sqlite3.h"
#include
intmain(intargc,char**argv)
{
intrc,i,ncols;
sqlite3*db;
sqlite3_stmt*stmt;
char*sql;
constchar*tail;
//打开数据
rc=sqlite3_open("foods.db",&db);
if(rc){
fprintf(stderr,"Can'topendatabase:
%sn",sqlite3_errmsg(db));
sqlite3_close(db);
exit
(1);
}
sql="select*fromepisodes";
//预处理
rc=sqlite3_prepare(db,sql,(int)strlen(sql),&stmt,&tail);
if(rc!
=SQLITE_OK){
fprintf(stderr,"SQLerror:
%sn",sqlite3_errmsg(db));
}
rc=sqlite3_step(stmt);
ncols=sqlite3_column_count(stmt);
while(rc==SQLITE_ROW){
for(i=0;i fprintf(stderr,"'%s'",sqlite3_column_text(stmt,i)); } fprintf(stderr,"n"); rc=sqlite3_step(stmt); } //释放statement sqlite3_finalize(stmt); //关闭数据库 sqlite3_close(db); return0; } SQLite入门与分析 (二)---设计与概念(续) 本节讨论事务,事务是DBMS最核心的技术之一.在计算机科学史上,有三位科学家因在数据库领域的成就而获ACM图灵奖,而其中之一JimGray(曾任职微软)就是因为在事务处理方面的成就而获得这一殊荣,正是因为他,才使得OLTP系统在随后直到今天大行其道.关于事务处理技术,涉及到很多,随便就能写一本书.在这里我只讨论SQLite事务实现的一些原理,SQLite的事务实现与大型通用的DBMS相比,其实现比较简单.这些内容可能比较偏于理论,但却不难,也是理解其它内容的基础.好了,下面开始第二节---事务. 2、 事务(Transaction) 2.1、事务的周期(TransactionLifecycles) 程序与事务之间有两件事值得注意: (1) 哪些对象在事务下运行——这直接与API有关。 (2) 事务的生命周期,即什么时候开始,什么时候结束以及它在什么时候开始影响别的连接(这点对于并发性很重要)——这涉及到SQLite的具体实现。 一个连接(connection)可以包含多个(statement),而且每个连接有一个与数据库关联的B-tree和一个pager。 Pager在连接中起着很重要的作用,因为它管理事务、锁、内存缓存以及负责崩溃恢复(crashrecovery)。 当你进行数据库写操作时,记住最重要的一件事: 在任何时候,只在一个事务下执行一个连接。 这些回答了第一个问题。 一般来说,一个事务的生命和statement差不多,你也可以手动结束它。 默认情况下,事务自动提交,当然你也可以通过BEGIN..COMMIT手动提交。 接下来就是锁的问题。 2.2、锁的状态(LockStates) 锁对于实现并发访问很重要,而对于大型通用的DBMS,锁的实现也十分复杂,而SQLite相对较简单。 通常情况下,它的持续时间和事务一致。 一个事务开始,它会先加锁,事务结束,释放锁。 但是系统在事务没有结束的情况下崩溃,那么下一个访问数据库的连接会处理这种情况。 在SQLite中有5种不同状态的锁,连接(connection)任何时候都处于其中的一个状态。 下图显示了相应的状态以及锁的生命周期。 关于这个图有以下几点值得注意: (1) 一个事务可以在UNLOCKED,RESERVED或EXCLUSIVE三种状态下开始。 默认情况下在UNLOCKED时开始。 (2) 白色框中的UNLOCKED,PENDING,SHARED和RESERVED可以在一个数据库的同一时存在。 (3) 从灰色的PENDING开始,事情就变得严格起来,意味着事务想得到排斥锁(EXCLUSIVE)(注意与白色框中的区别)。 虽然锁有这么多状态,但是从体质上来说,只有两种情况: 读事务和写事务。 2.3、读事务(ReadTransactions) 我们先来看看SELECT语句执行时锁的状态变化过程,非常简单: 一个连接执行select语句,触发一个事务,从UNLOCKED到SHARED,当事务COMMIT时,又回到UNLOCKED,就这么简单。 考虑下面的例子(为了简单,这里用了伪码): db=open('foods.db') db.exec('BEGIN') db.exec('SELECT*FROMepisodes') db.exec('SELECT*FROMepisodes') db.exec('COMMIT') db.close() 由于显式的使用了BEGIN和COMMIT,两个SELECT命令在一个事务下执行。 第一个exec()执行时,connection处于SHARED,然后第二个exec()执行,当事务提交时,connection又从SHARED回到UNLOCKED状态,如下: UNLOCKED→PENDING→SHARED→UNLOCKED 如果没有BEGIN和COMMIT两行时如下: UNLOCKED→PENDING→SHARED→UNLOCKED→PENDING→SHARED→UNLOCKED 2.4、写事务(WriteTransactions) 下面我们来考虑写数据库,比如UPDATE。 和读事务一样,它也会经历UNLOCKED→PENDING→SHARED,但接下来却是灰色的PENDING, 2.4.1、TheReservedStates 当一个连接(connection)向数据库写数据时,从SHARED状态变为RESERVED状态,如果它得到RESERVED锁,也就意味着它已经准备好进行写操作了。 即使它没有把修改写入数据库,也可以把修改保存到位于pager中缓存中(pagecache)。 当一个连接进入RESERVED状态,pager就开始初始化恢复日志(rollbackjournal)。 在RESERVED状态下,pager管理着三种页面: (1) Modifiedpages: 包含被B-树修改的记录,位于pagecache中。 (2) Unmodifiedpages: 包含没有被B-tree修改的记录。 (3) Journalpages: 这是修改页面以前的版本,这些并不存储在pagecache中,而是在B-tree修改页面之前写入日志。 Pagecache非常重要,正是因为它的存在,一个处于RESERVED状态的连接可以真正的开始工作,而不会干扰其它的(读)连接。 所以,SQLite可以高效的处理在同一时刻的多个读连接和一个写连接。 2.4.2、ThePendingStates 当一个连接完成修改,就真正开始提交事务,执行该过程的pager进入EXCLUSIVE状态。 从RESERVED状态,pager试着获取PENDING锁,一旦得到,就独占它,不允许任何其它连接获得PENDING锁(PENDINGisagatewaylock)。 既然写操作持有PENDING锁,其它任何连接都不能从UNLOCKED状态进入SHARED状态,即没有任何连接可以进入数据(nonewreaders,nonewwriters)。 只有那些已经处于SHARED状态的连接可以继续工作。 而处于PENDING状态的Writer会一直等到所有这些连接释放它们的锁,然后对数据库加EXCLUSIVE锁,进入EXCLUSIVE状态,独占数据库(讨论到这里,对SQLite的加锁机制应该比较清晰了)。 2.4.3、TheExclusiveState 在EXCLUSIVE状态下,主要的工作是把修改的页面从pagecache写入数据库文件,这是真正进行写操作的地方。 在pager写入modifiedpages之前,它还得先做一件事: 写日志。 它检查是否所有的日志都写入了磁盘,而这些通常位于操作的缓冲区中,所以pager得告诉OS把所有的文件写入磁盘,这是由程序synchronous(通过调用OS的相应的API实现)完成的。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- SQLite 入门 分析
![提示](https://static.bdocx.com/images/bang_tan.gif)