Database Storage

eXtremeDB supports the notion of logical database devices. Logical database devices are abstractions of physical storage locations that can be conventional memory (static or heap allocated memory in the application address space), shared memory (“named” memory shared by multiple processes), or persistent file system memory such as a simple file, a multi-file or RAID file, or even a raw disk partition. All access to eXtremeDB databases from applications using any of the eXtremeDB programming language APIs as well as through xSQL is managed via these logical memory devices. (Please see the Memory Management web page for more information on eXtremeDB memory management strategies for embedded systems.)

The application determines the size and location of the memory device, the type of memory and how the eXtremeDB runtime will use the device. This is referred to as device assignment which consists of:

A database is created “on top” of one or more devices. That means that a database logical structure (a database layout) is created by the eXtremeDB runtime and is independent of the physical layout (storage devices). An in-memory database will use a single conventional or shared memory device for all database data, indexes and metadata. A database with persistent classes (whose data is stored on persistent storage media) requires an array of four or more database devices. Regardless of its nature, any database must have at least one in-memory device. And databases can be “extended” by adding a storage device to the layout. Once the device has been added into the layout (i.e. the memory / storage is extended) that memory cannot be given back for other use by the application - it is managed exclusively by the eXtremeDB runtime.

Each device definition reflects the physical properties of the underlying storage:

The following diagram illustrates how in-memory and persistent devices might be configured to manage a hybrid database :