GBase 8a MPP Cluster Architecture: From Distributed Federated Architecture to High-Performance Analytical Engine

Published on 2026-05-09

This article demystifies the GBase 8a architecture, enabling your technical team to quickly grasp its design principles and technical strengths.', content_en = dbms_lob_new_clob('

In the era of big data and IT application innovation, GBase 8a MPP Cluster—a leading analytical distributed database in China—has been widely deployed in core analysis systems across finance, telecommunications, and government. This article demystifies the GBase 8a architecture, enabling your technical team to quickly grasp its design principles and technical strengths.

 

Product Positioning: Purpose-Built for Big Data Analytics

GBase 8a MPP Cluster is a next-generation analytical MPP database independently developed by General Data Technology, positioned as the core engine for petabyte-scale data analysis. Its primary use cases include:

Big Data Platform

Serving as the underlying compute and storage engine for data warehouses.

Comprehensive BI Systems

Supporting multi-dimensional analysis and reporting queries.

Data Warehouse and Data Mart

Delivering high-performance OLAP analysis capabilities.

Data Lakehouse

Unifying data lake and data warehouse workloads.

In-Database Data Mining

In-database machine learning algorithms (K-Means, logistic regression, SVM, etc.)

In short, if your business requires analyzing datasets ranging from hundreds of gigabytes to over a hundred petabytes, GBase 8a is purpose-built for these scenarios.

 

Overall Architecture: Distributed Federated Architecture

At its core, GBase 8a adopts an "MPP + Shared Nothing distributed federated architecture"—the fundamental differentiator from traditional single-node databases.

1. What Is Shared Nothing?

A Shared Nothing architecture means each node in the cluster is independent—it possesses its own CPU, memory, and local disk, communicating with other nodes over a TCP/IP network. There are no shared storage or memory resources.

This design delivers several key advantages:

Linear Scalability

Adding nodes linearly increases compute and storage capacity.

No Single Point of Bottleneck

Each node independently processes its own data shard.

Low-Cost Hardware

Commodity x86 servers are sufficient; no high-end shared storage is required.

2. What Is MPP?

MPP (Massively Parallel Processing) breaks down a large computing task into multiple sub-tasks, distributes them to many nodes in the cluster for parallel execution, and finally aggregates the results to return to the user.

Think of it like moving bricks: a traditional single-node database is one person moving all the bricks, while an MPP cluster is a team moving bricks simultaneously, each handling their own pile, and then counting the total—the efficiency is worlds apart.

 

Three-Tier Decoupled Architecture: Clear Separation of Duties

As shown in the architecture diagram, the system is clearly divided into three layers:

1. Business Access Layer

Enterprise business applications, BI analysis tools, and data loading clients connect to the cluster through standard SQL interfaces. These tools are completely unaware of how many machines are inside the cluster or how data is distributed across nodes—to the application, it appears as "one database."

2. Scheduling and Management Layer

This is the "brain" of the cluster, comprised of two major components:

GCluster (Scheduling Cluster):

The unified entry point for the cluster. It receives SQL statements from clients, parses and optimizes them, generates distributed execution plans, then dispatches tasks to individual data nodes for parallel execution. Finally, it collects results and returns them to the client.

GCware (Management Cluster):

The "housekeeper" of the cluster, responsible for maintaining cluster metadata, node status information, distributed locks, and other consistency services.

GCluster and GCware are usually deployed on the same server, collectively referred to as Coordinator nodes. The benefits of this design are:

  • Reduced server count: 3 Coordinator nodes meet cluster management needs.

  • Efficient communication: Co-locating GCluster and GCware minimizes heartbeat latency.

  • Simplified management: Only two roles need to be managed—Data nodes and Coordinator nodes.

Data nodes (GNode) are deployed independently, focused on data storage and computation. Odd numbers of Coordinator nodes (typically 3, 5, 7, or 9) are recommended to ensure the consistency election mechanism of the GCware cluster.

3. Storage and Compute Layer

This is the "muscle" of the cluster, composed of numerous GNodes (data nodes). Each GNode serves as both a storage unit and a compute unit—data is stored on local disks, and SQL execution is performed locally.
Each node stores one or more shards (primary replicas) of data, along with replicas (backups) of other shards, ensuring high data availability.
Architecture Highlights:

  • Shared Nothing architecture: Each node is independent and autonomous, sharing no storage.

  • MPP federated architecture: Multiple nodes work together, scaling linearly.

  • No single point of bottleneck: All nodes are peer-to-peer and scale horizontally.

  • Supports 1,000+ data nodes, handling 100PB+ of data.

 

Three Core Components: Seamless Collaboration

If GBase 8a were an efficient factory, its three core components would be the key production lines:

1. GCluster — The Cluster Commander

GCluster is the unified front-end portal for the cluster, performing a far more complex role than you might think:

SQL Reception

Accepts SQL statements from clients.

Query Rewrite

Performs equivalent transformations on SQL to find more efficient execution paths.

Optimizer Decisions

Uses both rule-based and cost-based approaches to select the optimal execution plan (e.g., which index to use, which JOIN method).

Distributed Execution Plan Generation

Decomposes the optimized query into multiple sub-tasks and distributes them to different GNodes for parallel execution.

Result Return

Dispatches sub-tasks to GNodes, collects returned results, and sends them back to the client.

2. GCware — The Cluster Brain

Although GCware does not directly process data, its role is critical:

  • Records and maintains cluster structure, node status, and resource status.

  • Manages distributed queuing locks and parallelism control.

  • For multi-replica operations, records and queries available nodes.

  • Ensures data consistency across nodes.

3. GNode — The Cluster Executor

GNode is where the real work happens. Each GNode runs the gbased service process, responsible for:

Data Storage

Utilizing columnar storage; data is organized by columns on local disk.

SQL Execution

Receives sub-tasks from GCluster and executes computations on local data.

Data Compression

Automatically compresses data efficiently to save storage space.

Intelligent Indexing

Automatically maintains coarse-grained indexes to accelerate data retrieval.

Multi-Replica Synchronization

Maintains data consistency with replica nodes through the GCSyncServer process in case of anomalies.

4. Component Collaboration Workflow

① Applications/BI Tools → GCluster (Accepts SQL → Parses → Optimizes → Generates distributed execution plan)

② GCluster → Multiple GNodes (Dispatches sub-tasks in parallel; each node independently computes its own shard data) 

③ When an anomaly occurs, GCSyncServer automatically synchronizes multi-replica data between GNodes 

④ GNode returns results → GCluster aggregates → Returns to client

5. Auxiliary Components

Beyond the three core components, GBase 8a includes several auxiliary components to ensure stable cluster operation:

GCMonit: Monitors the status of GCluster and GNode processes in real time, automatically restarting them if an anomaly occurs.

GCware_Monit: Monitors GCware process status in real time.

GCRecover: Manages data synchronization and recovery between multiple replicas.

GCSyncServer: Ensures consistency of multi-replica data files.

 

How Data Is Stored: Distributed Storage Mechanisms

GBase 8a performs extensive optimizations in data storage, which is key to its exceptional performance in analytical scenarios.

1. Columnar Storage: Read Only the Columns You Need

Unlike traditional row-based databases, GBase 8a uses columnar storage. Data is organized and stored on disk by columns (fields).

Imagine you have a user table with 100 columns, but you only need to query the "name" and "age" columns. In a row-based database, even though you need data from only two columns, the system must read the entire row (all 100 columns) from disk. In a columnar database, the system only reads the two columns you need, reducing I/O overhead to 1/50th of the original!

Advantages of columnar storage:

Reduced I/O

Reads only the required columns, dramatically reducing disk reads.

High Compression Ratio

Data types within a column are consistent, leading to higher compression (2x to 20x).

Hybrid Row-Column Storage

Accommodates wide-table scenarios, balancing query flexibility and performance.

2. Data Distribution: Three Strategies for Different Needs

How is data distributed across different GNode nodes? GBase 8a offers three strategies:

HASH Distribution

Principle: Distributes data to different nodes based on the hash value of a specified column.

Use case: Commonly used for columns involved in frequent JOINs, as data with the same hash value is co-located on the same node.

RANDOM Distribution

Principle: Data is randomly and evenly distributed across all nodes.

Use case: General scenarios with no specific distribution requirements.

REPLICATED Distribution

Principle: Each node stores a full copy of the data.

Use case: Ideal for dimension tables that are small in size but queried frequently.

3. Efficient Compression: 100GB Shrinks to 5GB

GBase 8a supports three levels of compression policies: instance-level, table-level, and column-level. It automatically selects the optimal compression algorithm based on data type and distribution patterns.

  • Compression ratios can reach 2x to 20x, far exceeding row-based storage.

  • Saves 50% to 95% of storage space.

  • Reduces I/O consumption, significantly improving data loading and query performance.

  • The compression and decompression process is completely transparent to users.

4. Intelligent Indexing: Trillion-Row Acceleration

GBase 8a''s intelligent indexing is a coarse-grained index technique with several standout features:

  • Automatically creates a data pack and builds an intelligent index for every 65,536 rows of data.

  • The intelligent index contains statistics such as minimum, maximum, null count, and SUM values.

  • Statistical values can be obtained without unpacking data, quickly filtering irrelevant data packs.

  • Index space occupies only 1% of the data volume (compared to 20%–50% for traditional indexes).

  • Automatically created with zero manual maintenance required.

 

How Queries Execute: The Full SQL Execution Flow

Now that we understand the storage mechanism, let''s walk through how a SQL query is executed in GBase 8a.

 

Step 1: Client Initiation

The application sends a SQL query request to the cluster via standard interfaces such as JDBC/ODBC.

Step 2: GCluster Processing

Upon receiving the SQL, GCluster performs a series of "brain operations":

1. Lexical/Syntax Parsing: Understands the SQL statement.

2. Query Rewrite: Applies equivalent transformations to optimize the execution path.

3. Optimizer Decision: Selects the optimal plan using both rule-based (RBO) and cost-based (CBO) approaches.

4. Distributed Execution Plan Generation: Determines JOIN order, data distribution strategy, parallelism degree, and target nodes.

Step 3: Parallel Execution on GNodes

GCluster dispatches the decomposed sub-tasks to the GNodes. Each GNode independently executes computation only on its own data shard—this is the core of MPP: break a big task into small tasks and have all nodes work in parallel.

Step 4: GCluster Aggregation

Each GNode returns its computed results, which GCluster then merges and sorts.

Step 5: Return to Client

The final result set is returned to the client application.

Key Features:

  • Distributed Parallel Planner: Processes operators in a distributed manner tailored to cluster characteristics.

  • Multi-table JOIN Optimization: Intelligently chooses among HASH JOIN, NEST-LOOP JOIN, and MERGE JOIN.

  • Asynchronous I/O Scheduling: Ensures efficient and reliable scheduling.

  • Read-Write Separation: Data loading and queries can proceed simultaneously without mutual interference.

 

Virtual Cluster: The Art of Logical Isolation

In real-world enterprise environments, a common scenario arises: multiple departments or business systems need to share a single database cluster, yet require their data to be isolated from each other without interference.

GBase 8a''s Virtual Cluster (VC) technology elegantly solves this dilemma.

Core Concepts

RC (Root Cluster):

The "chief steward" of the entire cluster, encompassing the GCluster Cluster, GCware Cluster, and the collection of all Data nodes. RC is not directly exposed to users for services; it is responsible for unified management and scheduling.

VC (Virtual Cluster):

A logical partitioning of Data Cluster nodes. Each VC owns a fixed number of Data nodes and operates independently within its virtual cluster boundary, without impacting others.

Free Nodes:

Reserved spare nodes used for rapid online scaling, shrinking, or replacing failed nodes.

Three Key Benefits

1. Unified Management, Single Entry Point

Although multiple VCs are partitioned internally, applications still perceive "one database." Users connect to any Coordinator node and transparently access the entire cluster.

2. Business Isolation, No Cross-Talk

Physical resource isolation is achieved between VCs: no matter how complex a query in VC1 is, it will not affect VC2''s performance. This makes multi-tenant, multi-business cluster sharing feasible.

3. Elastic Scaling, On-Demand Allocation

When a VC needs to scale up, nodes can be taken from the Free Nodes pool and added to that VC. The scaling process is online and does not interrupt business operations, yielding near-linear performance gains.

 

High Availability and Disaster Recovery: Multi-Layer Protection

Multi-Level High Availability System

For an enterprise-grade database, data security and system availability are paramount. GBase 8a builds a comprehensive, multi-level high availability system spanning from the process level to the cluster level.

Cluster-level: Active-active cluster (intra-city/remote disaster recovery), data synchronization.

Node-level: GCluster Failover mechanism, GCware virtual synchronization, GNode automatic synchronization.

Process-level: Real-time monitoring by GCMonit with automatic process recovery upon failure.

Data-level: Backup and recovery tool gcrcman, supporting both full and incremental backups.

Multi-Replica Redundancy Mechanism

Table data in GBase 8a is split into multiple shards, with each shard storing multiple replicas by default, distributed across different nodes.

For example, with 3 nodes:

Node1:

Primary: Shard A | Replica: Shard B

Node2:

Primary: Shard B | Replica: Shard C

Node3:

Primary: Shard C | Replica: Shard A

Each node acts as the primary node for some shards and a replica node for others. Nodes automatically synchronize data via the GCSyncServer process, ensuring consistency among multiple replicas.

Automatic Failover

When a node fails:

1. GCluster automatically detects the node failure.

2. Automatically triggers Failover, switching the primary service from the failed node to a healthy node where its replicas reside.

3. The cluster continues to provide services without interruption.

4. After the failed node recovers, it automatically synchronizes data from other complete replicas and immediately provides service once synchronization is finished.

 

Conclusion

As a mature analytical database developed in China, GBase 8a MPP Cluster embodies many principles of distributed system design:

  • Three-tier decoupling allows each component to fulfill its role, making expansion and maintenance easy.

  • The MPP + Shared Nothing architecture enables linear scaling of compute capacity.

  • Columnar storage + intelligent indexing + efficient compression form an iron triangle of high performance.

  • Virtual cluster technology strikes a perfect balance between unified management and business isolation.

  • Multi-replica + Failover mechanisms provide a solid foundation for data security and enterprise-grade high availability.

We hope this article has deepened your understanding of the GBase 8a architecture. If you are evaluating database options or encountering issues while using GBase 8a, feel free to leave a comment and start a discussion!