SQLite page Management

1 Page Manager: is the only module that accesses the local database and logs (via the operating system API). It abstracts random access systems or byte-oriented file systems into database files (page-based random access systems). It defines a set of file system-independent interfaces to access database files. The B-tree accesses the database using the interface of the page management module, rather than directly accessing the database or log files. The B-Tree treats the database file as a logical queue of uniform size. In addition to the memory database, the general database is the database file exists on the disk, when used to read into memory, operation, if necessary, then write back to memory. In general, database files are larger. Because of the limited memory, so in memory only a small fast database file, which is called the memory cache or data buffer, in SQLite called page cache.

For each database file, moving pages between files and caches is the basic function of the page manager. Mobile pages are transparent to B + trees and other high-level modules. The page manager is an intermediary between the file system and these high-level modules, which can directly access the page content and write the page back to the database file. He created an abstraction that the database is the queue of pages in main memory. The page Manager also provides additional functionality: Transaction Management (Implementation of acid, concurrency control and recovery, Atomic commit and rollback), Data Management (coordination of database file to buffer page read/write, file space management), log Management (Write records to the log file), Lock Management (ensure that the transaction has acquired a corresponding lock on the database file before accessing the file). In summary, page management implements the persistence of storage and the atomicity of transactions.

The upper modules are completely insulated from low-level lock and log management mechanisms, and they do not know the activity of locks and logs. B + trees see only the level of each transaction, regardless of the specific implementation. The page manager splits a transaction into a lock operation, a log operation, and a read and write operation to a database file. B + Tree Request a page by page number, and the page manager returns a pointer to the contents of the page that has been loaded into the buffer. When you make a change to a page, the B + Tree module notifies the page manager to save the appropriate information in the log file for possible recovery, and to obtain a lock on the corresponding database file. B + Tree Notifies the page manager when a page is exhausted, and writes back to the file if the page is changed.

2 Page Manager Interface structure: A data structure named Pager is implemented, and each open database file corresponds to a unique pager object, and the database file and pager object are almost equivalent. B + Tree When you want to use a database file, you create a new pager object that uses the object's handle to manipulate the file. The page module uses handles to track locks, log files, database status, log status, and so on for files.

3 Cache Management: Sqlitre maintains a separate page buffer for each open database file. If a thread opens the same file two or more times, the page manager only establishes a separate page buffer for the first open call. The In-memory database memory database does not design any external devices, but they are also treated like local files, all in a buffer. Therefore, the b/b+ tree uses the same interface to access the database.

The page buffer is in the application's memory space. The same page may also be cached by the operating system. When an application wants to read the contents of any file, the operating system uses its own cached backup and then uses the application's cache backup. SQLite's page buffers and the organization and management of the zone are independent of the operating system. Page cache management is the key to system performance.

3.1 Buffer organization: In order to speed up the search cache, in-memory cache items will have a better organization. SQLite uses a hash organization to cache pages, using a page slot to store pages in a table. The buffer is fully connected, that is, any slot can store any page. The Hashtable is initially empty, and the page manager creates a new slot and inserts it into the hash table. There is a maximum number of slots that a buffer can store, and there is no limit in the in-memory database (as long as the operating system allows the application's user space to grow).

Each page in the hash table has an object of type Pghder, followed by page image, followed by some private data (b + trees are used to store page-specific control information). The memory database does not have log files, so their recovery information is recorded in the Memory object. Pointers to these objects point to pointers to these objects after the private content is used by the page to manage the pointers. When the page manager puts the page into the buffer, it is initialized to zero. All the pages in the buffer can be accessed through a hash table,

SQLite page Management