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:
Log Cache — 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 writing.
System and Index Cache — 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.
Page Cache — 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.
Record Cache — 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.
