When evaluating database architecture, "cluster" doesn't always mean distributed.
GBase Database(GBase 8s) supports SSC (Shared Storage Cluster), an architecture where multiple database nodes share the same underlying storage.
The basic concept is:
Database Node 1
|
Shared Storage
|
Database Node 2
Unlike architectures where each database node maintains an independent copy of the data, GBase Database SSC allows multiple nodes to operate against a shared data layer.
Why Shared Storage?
The main value of GBase Database SSC is its fit for enterprise transactional workloads.
A shared-storage cluster can be attractive when the system requires:
Strong transactional consistency
Low database latency
High concurrency
Large shared data sets
High availability
For core OLTP systems, these requirements can sometimes matter more than simply adding more database nodes.
SSC Is Not the Same as Distributed Architecture
One common database selection mistake is assuming that distributed architecture is always the better choice.
It isn't.
Distributed databases are designed to solve problems such as horizontal data scaling and workload distribution.
GBase Database SSC addresses a different scenario: multiple database nodes working with a common storage layer.
The right question is therefore not:
"Is the database distributed?"
Instead, ask:
"Does my workload actually require distributed data processing?"
If the workload is transaction-heavy, requires strong consistency, and doesn't need horizontal data partitioning, shared-storage clustering can be an architecture worth evaluating.
What Should You Evaluate?
A GBase Database SSC POC should focus on real workload behavior rather than architecture diagrams.
Test at least:
Transaction performance
Measure TPS, latency, concurrency, and peak workload behavior.
Node failure
Verify how the system behaves when a database node becomes unavailable and measure the impact on applications.
Storage performance
Because storage is shared, evaluate I/O latency, throughput, redundancy, and failure behavior.
Application recovery
Don't test only the database. Check connection pools, transaction handling, and application recovery.
The goal is to answer one practical question:
Can GBase Database SSC meet the availability and performance requirements of our real workload?
Don't Ignore the Storage Layer
Shared storage is a major part of the SSC architecture.
That means storage cannot be treated as an infrastructure afterthought.
A production GBase Database SSC deployment should consider:
Storage redundancy
Network redundancy
I/O performance
Storage failure recovery
Backup and monitoring
Redundant database nodes do not eliminate the risk of a single-point-of-failure storage system.
The Bottom Line
GBase Database(GBase 8s) SSC provides a shared-storage cluster architecture for enterprise transactional workloads.
Its core idea is simple:
Multiple database nodes + shared storage + coordinated cluster operation.
The key is choosing architecture based on workload, not industry trends.
If your system is transaction-heavy, latency-sensitive, consistency-focused, and doesn't require distributed data processing, GBase Database SSC is worth evaluating.
For your OLTP workloads, what matters more: distributed scalability or shared-storage simplicity?
Top comments (0)