3.5.4. Falcon 内存缓存

  Falcon was designed to perform best on systems with generous amounts of memory. The memory caches utilized by Falcon are similar in some respects with other RDBMS's and MySQL engines; however, the cache structures offer a number of improvements over traditional memory caching strategies. The mechanisms used by Falcon with respect to memory caching include

Falcon被设计为在有大量内存的系统上最好的运行.被Falcon使用的内存缓存与其他关系型数据库的某些方面类似;但是缓存结构提供了一个与传统的内存缓存策略相比的大量改进.

    其机制包括:

    日志缓存 — log information is kept in memory and flushed to the Falcon Log when transactions commit. Falcon keeps eight 1 MB windows into the log file for reading and writin

    系统和索引缓存 — data needed by Falcon (table and field definitions, transaction state, etc.) is also maintained in memory for quick reference. In addition, local index accelerators represent index segments created by a running transaction are also stored in the system memory. When a transaction changes indexed fields, it builds an index accelerator section in system memory, representing its changes. On commit, all index changes for the transaction are written to the serial log in sorted order and later merged with the permanent index by the worker thread.

    页缓存 — database pages read from disk for a particular database. The page cache size is controlled by the falcon_page_cache_size parameter, which defaults to 4MB, and is set in the my.cnf file. Although record and index changes go to the serial log before being written to database pages, blob data is written directly into the page cache. This avoids logging large data items that are rarely referenced or changed by the transaction that creates them.

    记录缓存 — the record cache is a memory region devoted to holding rows that have been requested by end-user queries for a particular database or created by active transactions. Note that this cache differs from traditional data caches in that only specific rows needed by applications reside in the cache as opposed to entire data pages (which may contain only subsets of needed information). The record cache can hold several versions of records that have been modified or deleted. This technique guarantees that active data needed to satisfy user requests is in memory, shortens row access time, and reduces cache bloat by not including unrequested information. The record cache also assists in supporting the multi-version concurrency control (MVCC) mechanisms of the Falcon engine. The record cache is controlled by two parameters. The falcon_min_record_memory parameter (default 10MB) determines the minimum amount of RAM supplied to the record cache and the falcon_max_record_memory (default 20MB) limits the total amount of memory available to the cache.
   
    Because of the support the record cache supplies to transactions, a scavenge thread is used to ensure only "hot" data resides in the cache. When the falcon_max_record_memory limit is reached, Falcon surveys the demographics of the generational data in the cache, and removes the oldest generations. This process is more complicated than the standard LRU algorithm used by many database systems, but it is more efficient and faster.