[sqlite] SQlite source code analysis-architecture

Architecture

Internally, SQLite consists of the following components: kernel, SQL compiler, backend, and accessories. SQLite makes it easier to debug, modify and extend the core of SQLite by using virtual machines and virtual database engine (VDBE). All SQL statements are compiled into easy-to-read assemblies that can be executed in the SQLite virtual machine. SQLite supports databases up to 2 TB in size, and each database is completely stored in a single disk file. These disk files can be moved between computers in different byte order. These data are stored on the disk in the form of a B+tree data structure. SQLite obtains its database permissions based on the file system. The architecture diagram of SQLite is shown in Figure 1-1:

(1) Public interface (Interface)

Most of the public interfaces of the SQLite library are implemented by functions in the main.c, legacy.c and vdbeapi.c source files. These functions depend on some programs scattered in other files because they can access files in these files. The data structure of the scope.

(2) Lexical analyzer (Tokenizer)

When executing a string containing SQL statements, the interface program must pass this string to the tokenizer. The task of Tokenizer is to split the original string into tokens and pass these tokens to the parser. Tokenizer is written by hand, in the C file tokenize.c.

(3) Syntax parser (Parser)

The job of the parser is to assign specific meaning to the identifier in the specified context. The syntax analyzer of SQLite is generated by the Lemon LALR(1) analyzer generator. Lemon does the same work as YACC/BISON, but it uses a different input syntax, which is less error-prone. Lemon also produces a reentrant and thread-safe parser. Lemon defines the concept of a non-terminal destructor, it will not leak memory when it encounters a syntax error. The source file that drives Lemon can be found in parse.y.

(4) Code Generator

After the syntactic analyzer assembles the identifier into a complete SQL statement, it calls the code generator to generate virtual machine code to perform the work requested by the SQL statement. The code generator contains 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 documents cover most of the most important and meaningful things. expr.c handles the code generation of expressions in SQL. where.c handles code generation for WHERE clauses in SELECT, UPDATE, and DELETE statements. The files attach.c, delete.c, insert.c, select.c, trigger.c, update.c and vacuum.c handle the code generation of SQL statements with the same name (these files all call expr.c and where.c when necessary Routines in). The code for all other SQL statements is generated by build.c. The file auth.c implements the function of sqlite3_set_authorizer().

(5) Virtual Machine (Virtual Machine)

The code generated by the code generator is executed by the virtual machine. In general, the virtual machine implements an abstract computing engine designed for operating database files. It has a storage stack for storing intermediate data, and each instruction contains an opcode and no more than three additional operands.

(6) B-Tree (B-Tree)

경축! 아무것도 안하여 에스천사게임즈가 새로운 모습으로 재오픈 하였습니다.
어린이용이며, 설치가 필요없는 브라우저 게임입니다.
https://s1004games.com

A SQLite database is stored on disk in the form of a B-tree, and the implementation of the B-tree is located in the source file btree.c. Each table and index in the database uses a separate B-tree, and all B-trees are stored in the same disk file. The details of the file format are recorded in the remarks at the beginning of btree.c. The interface of the B-tree subsystem is defined in the header file btree.h.

(7) Page Cache

The B-tree module requests information from the disk in the form of fixed-size data blocks. The default block size is 1024 bytes, but it can vary between 512 and 65536 bytes. The page cache is responsible for reading, writing and caching these data blocks. The page cache also provides abstractions for rollback and atomic commit, and manages the locking of data files. The B-tree driver module requests a specific page from the page cache, and when it wants to modify the page, submit or roll back the current modification, it will also notify the page cache. The page cache handles all the troublesome details to ensure that requests can be processed quickly, safely, and efficiently.
The code implementation of the page cache is contained in a single C source file pager.c. The interface of the page cache subsystem is defined in the header file pager.h.

(8) OS interface

In order to provide portability between POSIX and Win32 operating systems, SQLite uses an abstraction layer to provide operating system interfaces. The interface of the OS abstraction layer is defined in os.h, and each supported operating system has its own implementation: Unix uses os_unix.c, Windows uses os_win.c, and so on. Each specific operating system implementation usually has its own header files, such as os_unix.h, os_win.h, etc.

(9) Utilities

Memory allocation and string comparison functions are located in util.c. The symbol table used by the parser is maintained by the Hash table, and its implementation is located in hash.c. The source file utf.c contains a Unicode conversion subroutine. SQLite has its own printf() implementation (with some extended functions), in printf.c, and its own random number generator, in random.c.

(10) Test Code

If you calculate the regression test script, more than half of the SQLite code will be tested. There are many assert() statements in the main code file. In addition, the source file test1.c implements some extensions only for testing purposes through test5.c and md5.c. The back-end interface of os_test.c is used to simulate a power failure to verify the crash recovery mechanism of the page cache.

[출처] https://programmersought.com/article/59155729592/