Geographically distributed database systems use remote replication to protect against regional failures. These systems are sensitive to severe latency penalties caused by centralized transaction management, remote access to sharded data, and log shipping over long distances. To tackle these issues, we present GaussDB-Global, a sharded geographically distributed database system with asynchronous replication, for OLTP applications. To tackle the transaction management bottleneck, we take a decentralized approach using synchronized clocks. Our system can seamlessly transition between centralized and decentralized transaction management, providing efficient fault tolerance and streamlining deployment. To alleviate the remote read and log shipping issues, we support reads on asynchronous replicas with strong consistency, tunable freshness guarantees, and dynamic load balancing. Our experimental results on a geographically distributed cluster show that our approach provides up to 14× higher read throughput, and 50% more TPC-C throughput compared to our baseline.

Cloud-native databases have been widely deployed due to high elasticity, high availability and low cost. However, most existing cloud-native databases do not support multiple writers and thus have limitations on write throughput and scalability. To alleviate this limitation, there is a need for multi-primary databases which provide high write throughput and high scalability. In this paper, we present a cloud-native multi-primary database, GaussDB, which adopts a three layer (compute-memory-storage) disaggregation framework, where the compute layer is in charge of transaction processing, the memory layer is responsible for global buffer management and global lock management, and the storage layer is used for page and log persistence. To provide multi-primary capabilities, GaussDB logically partitions the pages to different compute nodes and then assigns the ownership of each page to a compute node. For each transaction posed to a compute node, if the compute node owns all relevant pages of this query, the compute node can process the query locally; otherwise, GaussDB transfers the ownership of relevant pages to this node. To capture data affinity and reduce page transmission costs, GaussDB designs a novel page placement and query routing method. To improve recovery performance, GaussDB employs a two-tier (memory-storage) checkpoint recovery method which uses memory checkpoints combined with on-demand page recovery to significantly improve recovery performance. We have implemented and deployed GaussDB internally at Huawei and with customers, and the results show that GaussDB achieves higher throughput, lower latency, and faster recovery than state-of-the-art baselines.

In a classic transactional distributed database management system (DBMS), write transactions invariably synchronize with a coordinator before final commitment. While enforcing serializability, this model has long been criticized for not satisfying the applications' availability requirements. When entering the era of Internet of Things (IoT), this problem has become more severe, as an increasing number of applications call for the capability of hybrid transactional and analytical processing (HTAP), where aggregation constraints need to be enforced as part of transactions. Current systems work around this by creating escrows, allowing occasional overshoots of constraints, which are handled via compensating application logic.The WiSer DBMS targets consistency with availability, by splitting the database commit into two steps. First, a PROMISE step that corresponds to what humans are used to as commitment, and runs without talking to a coordinator. Second, a SERIALIZE step, that fixes transactions' positions in the serializable order, via a consensus procedure. We achieve this split via a novel data representation that embeds read-sets into transaction deltas, and serialization sequence numbers into table rows. WiSer does no sharding (all nodes can run transactions that modify the entire database), and yet enforces aggregation constraints. Both read-write conflicts and aggregation constraint violations are resolved lazily in the serialized data. WiSer also covers node joins and departures as database tables, thus simplifying correctness and failure handling. We present the design of WiSer as well as experiments suggesting this approach has promise.