DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
  1. DZone
  2. Data Engineering
  3. Databases
  4. The Client-Server Architecture and Execution Modes in CUBRID Database

The Client-Server Architecture and Execution Modes in CUBRID Database

Esen Sagynov user avatar by
Esen Sagynov
·
Jan. 24, 13 · Interview
Like (0)
Save
Tweet
Share
3.97K Views

Join the DZone community and get the full member experience.

Join For Free

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.

concept_of_cubrid_client_and_server.png

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.

clien_server_mode_and_standalone_mode.png

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.

CUBRID Database Architecture Execution (computing)

Published at DZone with permission of Esen Sagynov, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • ChatGPT: The Unexpected API Test Automation Help
  • Visual Network Mapping Your K8s Clusters To Assess Performance
  • The Top 3 Challenges Facing Engineering Leaders Today—And How to Overcome Them
  • How To Validate Three Common Document Types in Python

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: