Fornax Solutions; High Performance Compute ...
Speed Of Processing ...
Relational database technology has been around for many years and there have been offerings in object-oriented technologies, which met with varying degrees of success. Object-oriented databases are fundamentally much faster than relational databases because of the direct positioning and processing techniques inherent in the object design.
That said, speed in a database engine is a function many things. It is affected by the size of data under management, the access mechanisms employed, the amount of processing required to service the queries and functions such as insert /delete/ and update etc. Transaction processing, problem resolution, back-up/storage/recovery, validation services, transaction logging and internal requirements such as locking/multiple access user control and encryption are also all contributing factors.
In SQL, the engine needs to manage the data in ‘working sets’. A working set is data relevant to a query which is retrieved from the database file and used for queries resolution, i.e. filling in all the fields that are required, joining, accessing the indexes, and building optimal queries - and all this needs to be managed for multiple users and multiple sessions concurrently.
For SQL this is a real challenge, as it is a very resource hungry process and furthermore not all SQL engines manage this in the same way. This means there is a constant requirement for a Database Administrator to keep the database structure optimised so queries, can be satisfied as quickly as possible. A constant watch for exceptions and messages in the database engine logs must be kept, and these must be prioritized and resolved. This fulltime and demanding function requires skill and training and it becomes more of a problem as the size of the database increases, and the number of concurrent user accesses increase.
Finally, the access speed to the database, for query resolution in SQL, is heavily dependent upon the internal structure of the tables and by indexes.
With Fornax the situation is very different… data is stored only once and the indexes are extremely fast. They are also small. Concurrent accesses are managed quickly and logging and transaction management is done very quickly and uses the same structures. Therefore, objects which are added to, or deleted from, the database are stored in a way they can be used to replicate the database updates, rollback unwanted updates, and act as a transaction log for what has happened. These transaction logs can be used for database auditing purposes.
Fornax does not use working sets. Objects are managed in its cache. The number of objects in the cache are kept to an optimum, and because of the internal speed of the indexing and accessing system, the system processes requests very quickly. The level of concurrency is also kept to a minimum to reduce overhead in waiting-for-access times.
The effect is that the amount of data input in to the system is very quick and the database is very small.
This also takes care of the problems caused by locking, as the system hardly ever needs to rollback a request and reapply, should a lock up situation ever happen.
Memory requirements, as well as other requirements such as processing power, storage and network capacity with Fornax data are modest. The size of the system is irrelevant. Downscaling is very easy owing to the size of the engine (200KB), and larger scale computing is made possible by clustering the engines and the database. As a result the system in size and application is unlimited.
Fornax In Processing Systems ...
The size of the Fornax engine (<500KB) is a result of the object processing, definition and micro object processors from which the engine is constructed. This makes it possible to host the Fornax engine in firmware. The engine can then be used by various components of a computer or device to access, store and process various types of commands at a sub-operating system level. This provides for the dynamic configuration of a computer even without the operating system being present. The functionality provided by the operating system of the high order components of the computer can now focus on the management of applications and user-related issues, rather than hardware and configuration related functions.
This approach enables a new generation of computer and device configurations, where the hardware and communications layers become dynamic and can be controlled and configured independently of the operating system and application layers. Information interchange becomes secure and protocols and transmission mechanisms are now controllable and implemented independently of the quirks of operating system and service delivery suppliers.
Fornax utilizes its own processes independently from the operating system. A technique we termed ‘micro-scheduling’ is used by the engine (we have demonstrated running 30000 concurrent processes on normal i7 laptop, using 5% of processor capacity). Operating system interaction is not required. Fornax also has the ability of running scheduled activities, so that regular and conditional maintenance tasks can be programmed into the engine.
Fornax is designed with robotics in mind. The various parts of a robot each contains a processor, which controls the robot subsection independently, thus providing the capability of detachable, pre-programmed tools. Such an approach also allows for the use of smaller processors and memory, because a higher level of command and response exchanges are necessary to control and utilize the tool or limb. The robots ‘master control’ (brain) is now free to communicate and control the remainder of the robot at a high level whilst leaving the low-level sensors and reactions activities where it belongs.
Any system actually functions at this level – it is only a matter of scale. A large organization implements exactly the same paradigm. Data generation, collection, processing and are performed by different individuals at various levels, as part of the system.
Fornax, as a database engine, is able to process enormous amounts of data. One engine (such as implemented at chip level) is able to manage multiple database files, process them at execution level, and store and communicate requests and responses to clients via any available communications medium – bus, telecoms, file, etc. Data integrity remains paramount, as well as access, encryption, speed and size.
Fornax communicates and stores objects in a very compact and secure binary format. It operates according to laws implemented by tiny micro-code units, which implement these laws and cannot violate via processing any of these laws. The result is that the engine cannot malfunction, discards any unknown data and instructions, and can therefore not be affected by viruses or unauthorized accesses.
Requests and resulting responses are objects, which are understood by the Virtual Computer defined by Fornax and its Application API companion, called Polymach. Polymach is the gateway into and out of Fornax. Polymach is the only means by which Fornax Objects can be created and presented to an application program. The Polymach API is currently available on Windows platforms for C# programs, and will be released towards the end of 2015 for C and C++ on Windows, Linux, Android and iOS. Development platforms such as Visual Studio, Qt, and kits such as Eclipse can be used. Fornax application can also be developed without Polymach using the Fornax Programmer. The programmer creates, displays and executes objects directly, using the Fornax engine. It does not use any compilers, linkers or debuggers at all. There is no source code; objects are dynamically disassembled and presented. Objects could be presented in any alphabet, because objects are not defined via text editors.