This is the tenth article on CUBRID Internals. In the previous articles, I have discussed about Data Types, Domains, and Inheritance in CUBRID, how data is stored in CUBRID, etc. Today I will explain about two very important aspects of CUBRID Database - the execution mode and the client-server architecture. These are the most vague but interesting parts in understanding the internal structure of CUBRID.

There are two execution modes in CUBRID:

1. Client-server mode.
2. Standalone mode.

To understand them better, I need to explain about the client-server architecture of CUBRID.

The Client-Server Architecture in CUBRID

For a general database, the client-server architecture reminds many people of a DB client application and the DBMS server as shown on the left part of the following Figure 1. In other words in the common client-server architecture, the client application uses the database client library to connect to a database server and execute queries. In this case, the query processing is handled by the database server, not the client application. This is the common architecture.

Figure 1: Concept of CUBRID Client and Server.

However, for the internal structure of CUBRID, the terms client and server are slightly different.

In CUBRID, the client part is thicker than usually. It is not just an application that requests data processing from the DB server, but it has some DBMS functions like the DB object and query processing functions (e.g. query syntax analysis, optimization, and execution plan generation) as well as a simple network communication function.

On the other hand, the server part is classified into the storage system function layer that manages the database on a disk and the query processing function layer that executes SQL statements against this data on the disk.

Thus, CUBRID is based on the client-server DBMS architecture which has a different meaning than in a general DBMS. This client-server DBMS architecture allows CUBRID to enhance the query processing speed by distributing DBMS functions to multiple client hosts. The client hosts perform much of the heavy work such as query syntax analysis and optimization, execution plan generation, and caching the database objects. Eventually, the server is left with only executing the statement against the data volumes stored on the disk which allows to respond to more requests than otherwise would be possible. Thus, this client-server architecture provides significant performance increase.

Difference between client-server and standalone modes

Now, let's discuss the client-server mode and the standalone mode in CUBRID.

Single vs. multiuser access

The difference between these two modes is how the client and the server execute.

• In one mode, a process where the database volume is mounted runs as a server and client processes access this process.
• In the other mode, one process includes both the client function and the server function.

In other words, in the standalone mode only one user can access the database while in the client-server mode multiple users can access the database.

Libraries

The source code of CUBRID creates three libraries, libcubrid.so (the CUBRID server library), libcubridcs.so(the CUBRID client library) and libcubridsa.so (the standalone mode combining the server and the client code). The Makefile.am builds all these libraries. All of source code included in the libcubrid.so library and thelibcubridcs.so library are included in the libcubridsa.so library which means that the libcubridsa.so source code includes both parts: the part that acts as a server and the part that acts as a client. In addition, this libcubridsa.so library for standalone mode is one library linking with the two codes.

In the CUBRID source code, you can frequently find the condition compile macro definitions such as#if defined(SA_MODE), #if defined(CS_MODE), and #if defined(SERVER_MODE). This configuration implements both the client-server mode and the standalone mode with one CUBRID code.

Single-threaded vs. Multi-threaded

As you know, using CUBRID in client-server mode means that multiple users simultaneously use one database. Therefore, the CUBRID server should support this mode and be configured to run in multiple threads. However, the client-side code is configured to run with a single thread. In addition, the standalone mode where one process runs as both a client and a server runs with a single thread.

It is not usual for other DMBSs to support the standalone mode. CUBRID supports this mode to make it easy to implement some database management utilities. Among the utilities which should mount the database volume for modification, some of them should not be used by multiple users. In this case, the utilities are designed to run in the standalone mode. The most popular example of these utilities is compactdb which adjusts the location of objects in the database volume to reduce wasted space. The addvoldb utility, which creates the initial data volume, runs in the standalone mode, too. Another interesting thing is that the CSQL command line tool can run as the standalone mode as well. This is because the standalone mode includes all CUBRID functions, from the database volume file function to the SQL processing function, so it works as a DBMS by itself.

The CUBRID Broker program was developed by using only the client library. It serves as a bridge for various database drivers such as JDBC or ODBC to access the CUBRID server. Therefore, at the CUBRID server process side, the Broker is an application that uses the C API included in the libcubridcs.so library. When CSQL runs as the client-server mode, it becomes similar to the Broker. So, when you use utilities that show the internal information of the CUBRID server, such as killtran or lockdb, most of the clients in the list are shown as cub_casor csql. At the cub_server server process, the the cub_cs program, not the Java application, is a client.

Figure 2: Client-Server Mode and Standalone Mode.

Conclusion

Now you know about two different execution modes in CUBRID: the client-server mode and the standalone mode. In this article you have also learned that the client-server architecture of CUBRID is slightly different than in a common DBMS. In CUBRID, the client part is thicker and includes some of the DBMS functionality such as object and query processing which allows CUBRID to distribute these functionality to multiple client hosts to enhance the query processing speed.

In the next article I will continue my previous talk about Two-phase Locking mechanism in CUBRID. I will explain about how the Lock Manager works in CUBRID.