Disclaimer
Overview

Benefits

Hybrid Row/Column Storage

Ultra-High Performance Based on Fully Parallel Architecture

High Security and Availability

Smooth Business Migration

Complete Transaction Capabilities

Powerful Data Governance Capabilities
Features
Data Encryption
Encryption on the business side
In the business process, the encryption function within ADSQL-A for PostgreSQL is invoked, encrypting data before it is written to the database. Typically, the application will then read the encrypted data and decrypt it as needed.
Encryption built in ADSQL-A for PostgreSQL
The encryption process is transparent to the business, which has the following advantages:
1. Encryption operations (function calls) are separated from the business logic. The business solely focuses on writing the original data to the database kernel, while encryption calculations are handled internally within the database, without any involvement from the business.
2. The database maintains encryption algorithms, and tasks such as selecting encryption algorithms and managing keys are handled independently by the security administrator.
The kernel-based encryption calculation supports asynchronous encryption, enabling data encryption while maintaining stable system throughput. Supported encryption algorithms include AES-128, AES-192, AES-256, and SM4.
Support for Column Storage and Multiple Compression Algorithms
ADSQL-A for PostgreSQL provides support for column storage, allowing you to define data tables as columnar tables based on your specific business requirements. Typically, we recommend designating tables with wide widths and a need for high compression ratios as columnar tables. These tables support various compression algorithms, including delta, zlib, zstd, RLE, and bitpack, each offering different compression levels. For further details, please refer to the corresponding section in the user manual. ADSQL-A for PostgreSQL also features a new-generation columnar vectorized execution engine, ensuring high query performance for hybrid row/column storage and querying.
Data Masking
ADSQL-A for PostgreSQL offers transparent data masking, which seamlessly presents masked data to unauthorized users, ensuring imperceptibility.
Comprehensive Audit
ADSQL-A for PostgreSQL offers comprehensive auditing capabilities across multiple dimensions. Bypass detection auditing minimally impacts database operations. The available audit types include:
1. Statement audit: Audits specific types of statements.
2. Object audit: Monitors operations performed on specific database objects.
3. User audit: Tracks operations performed by specific database users.
4. Fine-Grained audit (FGA): Utilizes expressions as audit conditions and enables customized actions when an audit is triggered, such as sending emails or making phone calls.
Hot/Cold Data Separation
The kernel inherently facilitates hot/cold data separation, enabling businesses to present a unified database view without needing to distinguish between the underlying storage media.
1. To achieve hot/cold data separation and cost reduction, hot data and cold data are stored in distinct node groups with varying physical server configurations.
2. Scheduled backend tasks can autonomously migrate data based on configured hot/cold data rules, enabling automated hot/cold data separation within the system. This eliminates the necessity for businesses to actively manage the storage of hot/cold data in the cluster.
Please note that this feature is accessible in the Private Cloud Edition but not in the Public Cloud Edition.
Multi-Level Disaster Recovery
ADSQL-A for PostgreSQL ensures the cluster disaster recovery capabilities in multiple dimensions:
Strong Sync Replication
ADSQL-A for PostgreSQL provides robust synchronous replication. Maintaining identical data between primary and standby nodes forms the foundation of the entire disaster recovery system. In the event of primary node failure, seamless switching of the database service to the standby node occurs without any data loss. The mechanism of strong synchronous replication ensures that a transaction is only considered successful after the user request is executed and the log is securely written to the standby node, thereby guaranteeing constant data consistency between the primary and standby nodes.
Primary/Standby High Availability
ADSQL-A for PostgreSQL primarily employs a primary/standby high availability solution, utilizing multi-replica redundancy within each node group to minimize or eliminate service interruptions. In the event of primary node failure and inability to recover, an automatic selection of a new primary node from the standby nodes ensures uninterrupted service provision. Leveraging primary/standby high availability, ADSQL-A for PostgreSQL offers the following features:
1. Automated failover: In the event of primary node failure within the cluster, the system automatically designates a new primary node from the standby nodes, while isolating the failed node. The implementation of a strong synchronous replication policy ensures comprehensive data consistency between primary and standby nodes during failover scenarios, meeting stringent finance-grade standards for data consistency.
2. Failure recovery: In the event of data loss on a standby node caused by disk failure, the database administrator (DBA) can initiate recovery by rebuilding the standby node or adding a standby server to a new physical node. This process restores the primary/standby relationship, ensuring system reliability.
3. Replica switch: Each node within the primary/standby architecture, comprising a primary node and multiple standby nodes, hosts a full data replica that can be switched to by the database administrator (DBA) as required.
4. Do-Not-Switch configuration: It allows for the specification of a period during which failover operations will not be initiated.
5. Cross-AZ deployment: Even when primary and standby nodes are located in different data centers, real-time data replication is facilitated through Direct Connect. If the local node serves as the primary while the remote node acts as the standby, access is initially directed to the local node. In the event of local node failure or unreachability, the remote standby node is seamlessly promoted to a primary node to ensure uninterrupted service provision.
ADSQL-A for PostgreSQL implements a high availability solution centered on strong synchronous replication. In the event of primary node failure, the system promptly selects the most suitable standby node to seamlessly take over tasks. This transition occurs without user detection, and the access IP remains unchanged. Continuous 24/7 monitoring of system components ensures proactive management: if a failure occurs, the system automatically initiates node restart or isolation and selects a new primary node from the standby nodes to sustain service provision.