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.