Technically, this required a high-speed core database engine with a flexible trigger mechanism. This would allow 'business logic' to be attached to the database to perform scaling, alarm calculations, etc, and would also support 'active queries' so that client applications can be informed of relevant changes. The simple relational model was enhanced to support table inheritance; this allows better modelling or real-world relationships and simplifies queries, and also allows an object-oriented approach to defining the business logic. Holding the data in RAM, combined with the ability to define data persistence at the table and column level, gives high performance while minimising what needs to be journalled in normal operation. Finally, a suitable transactional model had to be developed that maintained data integrity while ensuring misbehaving clients could not block the database from real-time updates.
The initial design and development took three years but product enhancement has been going on ever since, to meet the long-term needs of our customers. Features added early in the product life include fault-tolerance (based on the master/hot-standby model for maximum performance coupled with low cost of deployment) and support for time-series data (where time-stamped samples have to be captured on the fly, and kept available for years to support trend diagrams and offline analysis); more recent features include read-only replicas (which can be used in chained and fan-out configurations for query offload), SQL enhancements, and enhancements to the active queries mechanism and the historian module (which handles the time-series data). These feature enhancements are usually planned in conjunction with our key customers, as their comments on the specifications help ensure the new functionality is of benefit to them.
Of course, there is also an ongoing programme to improve scalability, performance, and platform support; to add support for new standards; to reduce the footprint; and, to improve the usability and ease of deployment of the product. A key part of this work is to ensure the compatibility between releases is as high as possible, so that it is as easy as possible for customers to roll out new versions of our software into deployed systems - some of which can be very complex. ((For example, two of our customers have gas chromatographs with inbuilt Polyhedra databases, and use Polyhedra client-server functionality to allow these devices to monitor what is happening in neighbouring devices. If an oil refinery has thousands of such devices controlling the operation of the plant, it is important that new software can be rolled out to the devices one at a time without having to stop everything!)
An in-memory relational DBMS that runs in 32-bit mode, on a variety of operating systems and processor types. When run on 64-bit architectures, the database size is limited by the fact that the server runs as a single 32-bit process.
An in-memory DBMS that runs in 64-bit mode, and thus can handle much larger databases than Polyhedra32 IMDB - provided of course that it is being run on a machine with lots of RAM, and where the architecture of the machine and operating system allow a single process to access large amounts of RAM.
A relational DBMS that holds the data in a file rather than RAM. The file is assumed to be on some form of flash-based storage with wear-levelling, and the software uses a technique known as shadow paging to provide atomicity and data durability while avoiding unnecessary writes.
based on Polyhedra32 IMDB, this is a reduced-functionality version of Polyhedra32 IMDB that is made available for free, under a license that restricts further distribution. While omitting some features, it still supports Polyhedra's active queries, table inheritance and trigger code. It is available for use on Windows and some Linux platforms - including the Raspberry Pi.
(There is also a fifth branch: Polyhedra DBI, where the data is held in a 'foreign' database, which the DBI accesses via its ODBC driver. The DBI is only available on x86 platforms running Windows or Linux, and has no support for the historian or trigger code - but it emulates active queries on behalf of the client applications.)
All these products share the same code-base, and so have a large number of features in common and have a high degree of interoperability. For more information about each of the different products, click on the links above; for a quick overview of the differences between them, see the the product comparison chart