Open Source RDBMS - Seamless, Scalable, Stable and Free

한국어 | Login |Register

Current Events
Join our developers event to win one of the valuable prizes!
posted 2 years ago
viewed 3987 times
Share this article

Basic Operations of CUBRID Processes

This article is a part of "CUBRID Internals" series. In the previous article I have explained about CUBRID Processes and where to configure them. In this article I would like to dive into how those processes run. If you have not read the previous article, I recommend you to do so before reading further.

Figure 1 below illustrates the basic operation flow in CUBRID.

  • First, when a user enters the cubrid service start command, CUBRID gets started.
  • Then, the cub_master and cub_broker processes are started. At this time, a number of cub_cas processes will be started which corresponds to the value of MIN_NUM_APPL_SERVER parameter in the cubrid_broker.conf file.
  • Then, a user enters the cubrid server start demodb command which creates the cub_server process that mounts the demodb database volume. As described in CUBRID Processes, the cub_master process connects the cub_server process with the cub_cas process, which sends the requests, or the csql program.

cubrid_operation_procedure.png

Figure 1: CUBRID Operation Procedure.

As shown in Figure 1, if a JDBC application is connected to the server process which mounts the database volume file, the SQL statement can be executed in CUBRID. Two most popular methods to use CUBRID is to execute SQL manually using the command line CSQL Interpreter program or to write a program which uses various APIs like JDBC, PHP, Node.js, etc.

Note:
As we have discussed, the JDBC program connects to the database server through a broker while CSQL Interpreter directly connects to the database server bypassing the broker. This is an important difference between APIs and CSQL.

The CUBRID Manager database administration tool is developed on top of the JDBC driver. The SQL statement executed in CUBRID Manager are passed to the server through the JDBC API. Other database management functions that are available in CUBRID Manager (database creating/deleting, etc.) are executed through a management utility called CUBRID Manager Server which runs as a separate manager server daemon outside of the database.

Now, let's take a look at CUBRID Manager as an example to see how an SQL statement is executed in CUBRID. Refer to Figure 2 for this example.

  1. The SQL statement entered in the query editor of the CUBRID Manager (for example, SELECT * FROM olympic WHERE host_year > 1988 LIMIT 4;) is sent to CUBRID JDBC driver. This assumes that a database has already been selected in CUBRID Manager before executing this SQL, and the JDBC connection has been established.
  2. In the JDBC connection process, the connection is made to the port of the host specified in the JDBC connection information (JDBC Connection URL).
  3. The cub_broker process receives the connection and allocates a cub_cas process for the session to the connection.
  4. Then, it sends the socket connection to the cub_cas process so the connection between the JDBC driver and the cub_cas process is established.
  5. Back to the SQL statement execution, the JDBC driver included in the CUBRID Manager sends the SQL statement of the query editor to the connected broker, the cub_cas process.

The broker sequentially calls db_open_buffer(), db_compile_statement() and db_execute_statement() among C APIs provided by the client library, to execute the received SQL statement. The db_open_buffer() function parses the SQL statement, the db_compile_statement() function compiles the execution plan, and the db_execute_statement() function executes SQL by sending XASL (eXtended Access Spec Language) to the server.

sql_statement_execution_procedure.png

Figure 2: SQL Statement Execution Procedure in CUBRID.

As shown in Figure 2, the qmgr_execute_query() function is executed in the cub_cas, and the xqmgr_execute_query() function is executed in the cub_server process. The qmgr_execute_query() function in the client is the xqmgr_execute_query() function in the server. As shown above, CUBRID implements a communication interface of Remote Procedure Call (RPC) between a client and a server. In the server, the qexec_execute_query() and qexec_execute_mainblock() functions of the query processing module are used to execute XASL.

If you are interesting how queries are processed in CUBRID, I recommend you to read CUBRID Query Processing which provides the detailed step by step explanation using real examples.

By Park Kieun, Senior Software Engineer and Architect at Service Platform Development Center & IT Service Center, NHN Corporation.



comments powered by Disqus