The architecture of the SQLite database (translated from sqlite.org)

About Us
This document describes the architecture of the SQLite library, which is useful for those who want to understand and modify the internal working mechanism of SQLite.
Shows the main components of SQLite and their interrelationships, and the following describes each part. (see Http://www.sqlite.org/arch2.gif for specific figures)

This document describes the SQLite version 3.0, which is similar to version 2.8 or earlier, but differs in detail.
$ $ interface
Although some functions are distributed among other files, the common interface functions of the main SQLite libraries are implemented in the MAIN.C,LEGACY.C and VDBEAPI.C source code files. The sqlite3_get_table () function is implemented in TABLE.C, sqlite3_mprintf () is implemented in PRINTF.C, and Sqlite3_complete () is implemented in TOKENIZE.C. The TCL interface is implemented in TCLSQLITE.C. More complete information about the C interface of SQLite is described in http://www.sqlite.org/capi3ref.html.
To avoid naming conflicts with other software, all external symbols in the SQLite library are prefixed with sqlite3. These symbols are intended for external use, in other words, all symbols starting with sqlite3_ form the SQLite API.
$ $ Lexical analyzer
When an SQL statement executes, the interface first passes the string containing the SQL statement to the lexical parser for processing. The lexical parser is responsible for dividing the string into one lexical unit, then passing the lexical unit to the parser, which is implemented in the Tokenize.c file, which is hand-coded and not generated using tools such as Lex.
It is important to note that in this design, the lexical analyzer calls the parser, familiar with YACC and bison generally always call the parser in the parser, SQLite author both methods have tried, found in the lexical parser to call the parser better.
$4 Parsing Parser
The parser understands the meaning of the unit based on the context of the lexical method. SQLite parser is generated using the LALR (1) tool generator of lemon (http://www.hwaci.com/sw/lemon/). Lemon and Yacc/bison tools are similar, but Lemon uses a different input syntax, which makes it more difficult to make mistakes. Lemon can produce a reentrant and thread-safe parser, lemon defines a non-terminator destructor so that there is no memory leak when syntax errors occur. The input file for the Lemon parser is defined in PARSE.Y.
Since lemon is not a common program, its full source code is only a C file in the SQLite tool subdirectory. The lemon document is in the Doc subdirectory.
$ A Code generator
When the parser finishes parsing the SQL statement, it calls the code generator to generate code that executes on the virtual machine, which executes according to the requirements of the SQL statement. Code generators are included in many files: attach.c, auth.c, BUILD.C, delete.c, Expr.c, insert.c, PRAGMA.C, select.c, Trigger.c, update.c, VACUUM.C, and Where.c. These files are where our magic happens. EXPR.C handles the code generation of the expression, where.c the code generation that handles the WHERE clause in the Select,update and DELETE statements, ATTACH.C, delete.c, insert.c, select.c, trigger.c UPDATE.C and VACUUM.C handle code generation for SQL statements with the same name, and each of these files calls functions in Expr.c and where.c, if necessary. Other SQL statements are implemented in BUILD.C, and the auth.c file implements the function of the Sqlite3_set_authorizer () function.
$6 virtual Machines
The program generated by the code generator runs on the virtual machine, and the information for that virtual machine is described in document Http://www.sqlite.org/opcode.html. In summary, a virtual machine implements an abstract computing engine that is used to manipulate database files. The virtual machine has a stack to hold the middle state of the calculation, each of which includes an opcode and up to three operands. Virtual machines are implemented in VDBE.C. The virtual machine has its own header file: The Vdbe.h file defines the interface of the virtual machine and the SQLite library, and the VdbeInt.h file defines the structure of the virtual machine. The Vdbeaux.c file contains tools that are used by virtual machines and interface modules. The Vdbeapi.c file contains the external interface of the virtual machine, such as sqlite3_bind_ ... Functions such as the. strings, integers, floating-point numbers, and BLOB types are all present in an internal object called MEM, an internal object implemented in the Vdbemem.c file.
SQLite uses the callback C language function to implement the functions of the SQL statement. Even built-in SQL functionality is implemented in this way. Most of the SQL built-in functions, such as coalesce (), count (), substr (), etc., are implemented in FUNC.C. Date and time conversion functions are implemented in DATE.C.
$7 B-Tree
SQLite uses the B-tree to implement the database, and B-tree is implemented in the Btree.c file. Each table and index in the database uses a separate B-tree. All B-trees are stored in a disk file. The details of the database file format are detailed in the comments in the start section of the btree.c file.
The interface of the B-tree subsystem is defined in the header file btree.h.
$8 Page Cache
The B-Tree module uses a fixed block size to request information from the disk. The default block size is 1024B, but can be adjusted from 512 to 65536B. The page cache is responsible for reading, writing, and caching these blocks. The page cache also provides rollback and atomic commit function abstraction and lock operations for database files. The B-Tree driver obtains the page from the page cache, and notifies the page cache when the program is modified, committed, or rolled back, and the page cache handles all of these troublesome details to ensure that the request is handled quickly, safely, and efficiently.
The code that implements the page caching mechanism is in a single C file pager.c. The interface of the page cache subsystem is defined in Pager.h.
$9 Operating System interface
To improve portability in POSIX and WIN32 systems, SQLite and the operating system interface use an abstraction layer. The interface for this abstraction layer is defined in os.h. Each operating system is particularly self-fulfilling: Os_unix.c is UNIX, os_win.c is Windows, and so on. Each operating system-related implementation is especially its own header file: Os_unix.h, Os_win.h, and so on.
$ $ Tool Program
Memory allocation and case insensitive string comparison functions are implemented in the Util.c file, and the symbol table used by the parser is a hash table, which is implemented in HASH.C. The UTF.C file contains Unicode conversion functions. SQLite has its own printf () function implementation, which is defined in PRINTF.C, and the random number function implementation, which is implemented in RANDOM.C.
$11 Test Code
More than half of the code is for testing services. There are many assert () functions in the main code file. Test1.c to TEST5.C and md5.c are used for testing. OS_TEST.C simulation verifies the disaster recovery capability of the page cache mechanism after power failure.

Http://www.cnblogs.com/qiubole/archive/2007/11/21/966678.html

The architecture of the SQLite database (translated from sqlite.org)