Next Page Prev Page Main Index Home

How is this possible?
No car goes 1500 MPH

MPbase is capable of performance that should not be possible given the hardware. How is this possible? The answer is simplicity. A simplicity that is only possible with a resource centric architecture and content addressable memory (CAM) schema. Computer systems have over the years developed into an unbelievable level of complexity. Systems have layers upon layers of code. Each layer's goal is to hide the complexity of the layers under it. This hiding makes things APPEAR to be simpler, when in fact each layer actually makes things more complex.

MPbase is only possible due to an understanding of all parts of the DBMS problem. They include, the data manipulation itself, operating system architecture, and the underlying hardware architecture. Not long ago such a layer free system would be highly closed and proprietary. Today, however, both the OS, and the hardware have been standardized to the point that this is not only possible but practical.

Most parts of an (R)DBMS are only needed to internally support the layers. Very few of the parts are actually doing end user useful work. It is amazing how little database functionality is really required to directly support the end user. Working with the OS and using a CAM schema are the keys to removing (R)DBMS layers.

Much the same can be said for the OS. Most of the OS is there to support the rest of the OS, not the real end user useful work. Most of the internal OS functionality is there to support "tricks." Each trick is intended to speedup the system. However, each trick adds to the system complexity and overhead. The solution is resource centric processing.

A traditional (R)DBMS Vs MPbase

Doing the end user usefull work

MPbase is capable of doing the same end user useful work with far less system effort. On any given hardware platform there is only one way to truly speed a system up. DO LESS WORK. The way to reduce the workload is to understand what tasks are not essential to end user functionality and minimize their impact on the system.

Next Page Prev Page Main Index Home © 1998-2004 NPSI