Article : Database Server Architecture

Database Server Architecture

The Mimer SQL DBMS is based on client/server architecture. The Database Server executes in one single, multi-threaded process with multiple Request and Background threads. On some platforms Communication threads are used. The Mimer SQL architecture is truly multi-threaded, with requests being dynamically allocated to the different Request threads. As threads scale very well over multiple CPUs, Mimer SQL is particularly well suited for symmetric multiprocessor (SMP) environments. By the use of threads within the Database Server, optimal efficiency is achieved when context-switching in the Database Server.

The use of a separate Database Server Process guarantees that a program error in an application process cannot corrupt the shared data areas that control the database server. It also ensures that the application can only view data that has been formerly passed to the client side, which is extremely important from a data security point of view.

The Communication threads are used to handle parts of the communication between the applications and the database server. On some platforms other mechanisms are used to handle the communication between the applications and the database server. Whatever the mechanism, all communication with the database server is multi-threaded, allowing large numbers of simultaneous user requests.
Both local and remote applications are handled directly by the Database Server. This means that in Client/Server environments, where Mimer SQL executes in a distributed environment with the client and server on different machines, all remote clients connect directly to the Database Server. Thereby avoiding any additional overhead of network service processes being started, either on the client or on the server machine.
The Request threads perform the SQL operations requested by the applications. When the Database Server is requested to perform a SQL operation it allocates one of its Request threads to perform the task. When the SQL operation is complete the result is returned back to the application, and the Request thread that has performed the operation returns to a waiting state until it receives another server request. Since the SQL operations are evaluated entirely within the Database Server, inter-process communication is reduced to a minimum.
When a SQL query or a stored routine is executed by a Request thread, the compiled version of the query or the routine is stored within the Database Server. In this way the same, compiled version of the query or routine can be used again by other applications. This leads to improved performance, since a SQL query or a stored routine only need to be compiled once by the Database Server.
The Background threads perform database services including all database updates, online backup and database shadowing. These services are performed asynchronously in the background to the application processes, which means that the application process does not have to wait for the physical completion of a transaction or a shadow update, but can continue as soon as the transaction has been prepared and secured to disk.
I/O-operations are performed in parallel directly by the request and background threads using asynchronous I/O. Thereby any need for separate
I/O-threads are avoided.