posted 3 years ago in CUBRID Life category by Esen Sagynov
Last time, I examined CUBRID-based support tools as a part of the CUBRID Feature Series. See Documentation -> Tutorials on the homepage for information on how to use the tools covered in the last post of this series. If there is something that is missing or if there is anything that is difficult to understand, you can inquire by replying to this message. After carefully considering what first-time CUBRID users would want to know about CUBRID the most, I decided to examine the architecture of CUBRID in this post.
What is the biggest difference between CUBRID and other DBMSs?
There are many, but the architecture of the DB/AP connection is the biggest. What architecture am I going to talk about?
It is the difference between 2-Tier and 3-Tier architectures. Each architecture type is described briefly below (from a Software perspective).
1) 2-Tier: An architecture in which the Presentation/Business Logic is located on the Client Side, and the database on the Server Side. Most of well-known DBMSs have this 2-Tier architecture.
2) 3-Tier: An architecture in which the Presentation Logic is located on the Client Side, and the Business Logic/database on the Server Side. Application and Database Servers used for Internet service are examples of this architecture. CUBRID is a DBMS with a 3-Tier architecture.
Compared to the past service environments, in the recent Internet service environments, the 3-Tier architecture is more advantageous than the 2-Tier architecture.
Under the internet service operated by multiple connectors, the 3-Tier architecture has many advantages, including scalability, reusability, and efficiency in system management, but overload-related performance and utilization of resources might be the biggest advantage.
Currently, many DBMSs support the 3-Tier architecture using WAS, but CUBRID was developed with the 3-Tier architecture.
CUBRID can be divided into the following components.
CUBRID DB Server ------ CUBRID Broker ------- APIs (JDBC, ODBC, etc.)
Users with no CUBRID experience might wonder about the CUBRID Broker part.
Broker, a part of the CUBRID product, is a middleware that receives requests from AP and delivers them to the DB.
The following is the architecture of CUBRID.
Each part (Application Client, Cub_Broker, and Database Server) can be located on each server.
You can achieve load balancing because CUBRID, Broker and AP (program) exist separately. You can also distribute servers according to the utilization of each resource.
For details about each item (cub_cas, cub_broker, etc.) in the above architecture, see the manual.
In the architecture described above, the user does not need to try direct access to CUBRID. That is, the user does not need to find the port for the DB. In this type of architecture, communication is made with the Broker port and the number of Brokers and resources can be adjusted.
So far, I have briefly talked about the architecture of the CUBRID product. Next time, I will examine CSQL. Let's take a look at the valuable features hidden in CSQL.