A high-performance, low-footprint relational database system designed for use with Flash memory
Polyhedra FlashLite is a high-speed relational database system specially designed for use with flash-based file systems. It takes responsibility for preserving and making accessible the data needed by the component parts of an embedded system, freeing up developers to concentrate on the features that distinguish their products with capabilities like:
-
Small footprint to keep deployment costs down
-
Standards-based to ease adoption costs
-
ACID-compliant transactions
-
Standalone or fault-tolerant configurations
-
Triggers and active queries for enhanced responsiveness
-
Client-server for protection and to allow remote access
|
|
|
|
Polyhedra FlashLite is a relational database system, designed for use in flash-based embedded systems.
Polyhedra FlashLite is a database system (DBMS). It stores information with a well-defined interface for retrieving and updating it. It isolates the application writers from the details of data storage: they do not need to know how it is preserved, or the format of data on the storage media.
Polyhedra is a relational DBMS. This is the most widely-known, and widely-adopted database model. Basically, data is stored in named tables; each table has a number of named columns (‘attributes’), each with an associated data type, and each row in the table corresponds to a data record. Polyhedra is SQL based - again, the most widely-used language for setting up, querying and manipulating databases.
In common with other relational database systems Polyhedra is ‘transactional’. This means that operations are grouped together and applied atomically: the mid-transaction state is invisible to other applications, and if a transaction fails, the database ‘rolls back’ to the state it was in before. As the database system enforces these properties, even over system failure, applications do not have to worry about data consistency.
|
|
Like other relational database systems, databases in Polyhedra are flexible. Not only can tables be added or dropped on the fly, but it is also possible to add and drop individual columns, without affecting running applications (if they are not using these columns). As Polyhedra uses a familiar, transactional data model, with familiar interfaces (SQL, ODBC and JDBC), it is easy for people to adopt it.
Polyhedra IMDB is fully-client server, and the communication protocols are platform-independent. In addition, the database files are fully portable, so a file generated on a host platform can be used as the seed for a database running on a different target platform regardless of issues such as endian mismatch. Polyhedra is standards-based, and the main client libraries are ODBC (for C/C++ programmers) and JDBC (for Java).
|
|
|
- Standards-based: use of SQL, ODBC and JDBC eases adoption costs
- RAM cache for high-speed queries; updates use ‘shadow paging’ for performance and to reduce strain on flash memory
- Active queries keep clients up to date without the need for polling; active trigger code enforces integrity and performs ‘knock-on’ changes
- Hot-standby configurations supported for use in high-availability systems.
|
|
|
Polyhedra IMDB and Polyhedra FlashLite
Polyhedra is a family of DBMS products, sharing very similar functionality. The two main products are Polyhedra IMDB and Polyhedra FlashLite. Both are relational database systems, sharing the same SQL engine, the same client server architecture and protocols, and both support the hot-standby model for use in high-availability systems. The primary difference between the two is in how they hold and preserve data:
- Polyhedra IMDB holds the working copy of a database in memory. Data is preserved by means of on-demand snapshots, supplemented by a journal-logging mechanism: at the end of each successful transaction that altered persistent data, a journal record is appended to the snapshot file, recording what was changed in the transaction. When the system starts up, the shapshot is read, and then all appended journal records are applied (up to, but not including, the first incomplete or corrupted record).
- Polyhedra FlashLite holds the data in a file (assumed to be on a flash filing system) with a configurable-sized RAM cache. A technique known as ‘shadow paging’ is used to ensure transactions are atomic and durable: the database file is treated as a series of pages, with a page map allowing logical pages to be relocated within a file. When a transaction alters a logical page, the updated version is written to a spare page; at the end of the transaction, the modified page maps are written out, and the pages that hold the old versions of data are marked as spare. If the system fails before the updated maps are written out, the database can use the old version of the maps to recover the previous state.
|
|
As Polyhedra FlashLite and Polyhedra IMDB are essentially identical from the application writers’ point of view - and even use exactly the same client libraries, the decision as to whether to use one or the other boils down to the issues of footprint and performance:
- Polyhedra IMDB needs more RAM, but offers greater performance when updating the database
- Polyhedra FlashLite can run in as little as 1MB or RAM (for code and cache), though it can be configured with a larger cache to speed up the performance, particularly for queries and large transactions.
The compatibility between the two products is so high that it is even possible to start up a FlashLite database using a saved Polyhedra IMDB database as a seed, or to run a Polyhedra FlashLite server as a standby to a Polyhedra IMDB server - making it possible to migrate a fault-tolerant system using Polyhedra IMDB to one using Polyhedra FlashLite technology with zero downtime.
|
|
|
|