The eXtremeDB in-memory database implementation was originally created when RAM memory was predominately a random access device; i.e. accessing any place in memory takes the same amount of time and CPU cycles. This model was accurate until recent years for embedded devices as well as for server-type architectures. CPUs were slow enough and RAM small enough that reading and writing the RAM directly didn't create a significant bottleneck. However in recent years even typical desktop CPUs possess deep cache hierarchies - at least a sizable L1 and L2 cache - to prevent the CPU from being dominated by RAM accesses. The CPU cache provides much faster access (an order of magnitude or more faster) than normal RAM. Data structures and algorithms that efficiently exploit the CPU cache can perform dramatically more quickly than those that don't. Furthermore, nowadays large memory access algorithms in multiprocessing systems are almost always implemented through the NUMA memory architecture providing other performance advantages and challenges for data and index optimization.
Key-value-inclusive Indexes
eXtremeDB allows a “key-value-inclusive” or “cache-oblivious” implementation for in-memory (
transient) database classes that expedites access for certain access patterns. In particular experiments with very large B-Tree indexes show significant performance improvements. Also, thetrigramindex is implemented via the “key-value-inclusive” tree because it is much more efficient to keep 3 extra bytes (trigrams) on the index page than to simply store an 8-byte object address which requires further access steps.(Note that the Java, C# and Python APIs do not currently allow inclusive indexes.)
Covering Indexes
If all the fields requested in an index search are available in the index, then the runtime doesn't have to look up the object covered by the index again. This can significantly increase the performance of searches. Since all the requested fields are available within the index, the index is called a “covering index”.