Learning Product Knowledge

openGauss is a relational database. It uses the client/server, single-process multi-thread architecture, and supports standalone and one-primary and multiple-standby deployment modes. In the primary/standby deployment mode, the standby node can be read, and HA and read expansion are supported.

Product Features

Compared with other open-source databases, openGauss has the following characteristics:

High performance
- Provides the multi-core architecture-oriented concurrency control technology and Kunpeng hardware optimization, and achieves that the TPC-C benchmark performance reaches 1,500,000 tpmC in Kunpeng 2-socket servers.
- Uses NUMA-Aware data structures as the key kernel structures to adapt to the trend of using multi-core NUMA architecture on hardware.
- Provides the SQL bypass intelligent fast engine technology.
High availability (HA)
- Supports multiple deployment modes, such as primary/standby synchronization, primary/standby asynchronization, and cascaded standby server deployment.
- Data page CRC check is supported. Damaged data pages are automatically restored by the standby node.
- The standby node recovers in parallel and can be promoted to primary to provide services within 10 seconds.
High security
Supports security features such as fully-encrypted computing, access control, encryption authentication, database audit, and dynamic data masking to provide comprehensive end-to-end data security protection.
Easy O&M
- Provides AI-based intelligent parameter tuning and index recommendation to automatically recommend AI parameters.
- Provides slow SQL diagnosis and multi-dimensional self-monitoring views to help you understand system performance in real time.
- Provides SQL time forecasting that supports online auto-learning.
Fully open
- Adopts the Mulan Permissive Software License, allowing code to be freely modified, used, and referenced.
- Fully opens database kernel capabilities.
- Provides excessive partner certifications, training systems, and university courses.
- Compared with other open-source databases, openGauss provides multiple storage modes, NUMA-based kernel structure, and high availability.

Software Architecture

openGauss includes the openGauss servers, client driver, and OM modules. This chapter describes the relationship between these modules.

Figure 1 shows the openGauss software architecture. In the documentation of openGauss, each openGauss server is called an instance.

Figure 1 Software architecture

For details about the meaning of each module in the figure, see Table 1.

Table 1 Module description

Name	Description	Remarks
OM	Operation Manager provides management interfaces and tools for openGauss routine O&M and configuration management.	Different from the server and client driver modules, the OM provides users with tools to manage openGauss instances.
Client driver	The client driver receives access requests from applications and returns execution results to the applications. It communicates with openGauss instances, delivers SQL statements to openGauss instances, and receives command execution results.	It receives the access requests from applications, and returns the execution results to the applications. The client driver is responsible for establishing a link to the openGauss instance, transmitting an SQL command of an application to the openGauss instance, and receiving the command execution result of the openGauss instance. The client driver and application run in the same process and are deployed on the same physical node.
Primary/Standby openGauss server	The primary/standby openGauss server stores service data (stored by row-store, column-store, or memory table), executes data query tasks, and returns execution results to the client driver.	It stores service data, executes data queries, and returns executed results to the client driver. openGauss instances are classified into primary and standby instances. One primary and multiple standbys are supported. You are advised to deploy the primary and standby openGauss servers on different physical nodes.
Storage	It functions as the server's local storage node to store data permanently.	-

Typical Networking

To ensure the security of application data, you are advised to divide an openGauss typical network into two independent networks: front-end service network and data management and storage network.

Figure 2 Typical networking

Table 2 describes the network division.

Table 2 Network division

Type	Description
Database management and storage network	The database administrator uses this network to invoke OM scripts to manage and maintain openGauss instances. It is also used for openGauss primary/standby communication networking. The database management and storage network are also used for applications to execute system monitoring.
Front-end service network	External clients access the openGauss database through this network.

The typical networking has the following advantages:

The service network is isolated from the database management and storage network, effectively protecting the security of back-end storage data.
The isolation between the service network and database management and storage network prevents attackers from managing database servers through the Internet, improving system security.

Network exclusiveness and 1:1 bandwidth convergence ratio are the basic requirements for openGauss database network performance. Therefore, in the production system, the back-end storage network shown in Figure 2 must meet the requirements of exclusiveness and 1:1 bandwidth convergence ratio. For example, in Figure 3, the Fat-tree networking is used. To achieve a convergence ratio of 1:1, the bandwidth doubles each time the switching network layer is increased by one layer. In the figure, each bold line indicates the 80GE bandwidth, that is, the sum of the bandwidth upper limits of eight physical machines. At the access layer, each switch provides 160GE downlink bandwidth and 160GE uplink bandwidth. The convergence ratio is 1:1. The access bandwidth of each switch at the aggregation layer is 320GE.

For the test system, the preceding requirements can be lowered.

Figure 3 Database management and storage network