In Serverless mode, AnalyticDB for PostgreSQL provides features such as separation of computing and storage resources, elastic scaling within seconds, and real-time data sharing across instances. These features are implemented based on the resource pooling and massive storage capabilities of cloud infrastructures and massively parallel processing (MPP), online and offline data processing, and Serverless technologies.

Description

In Serverless mode, AnalyticDB for PostgreSQL decouples computing and storage resources so that they can be scaled with different proportions. Storage resources remain billed on a pay-as-you-go basis, but computing capabilities can be independently scaled to meet business requirements. This reduces storage costs and improves efficiency.

AnalyticDB for PostgreSQL in Serverless mode provides the following advantages over AnalyticDB for PostgreSQL in elastic storage mode:

  • Reduces storage costs and enables on-demand resource use. You can use AnalyticDB for PostgreSQL in Serverless mode to implement cost-effective data analysis without the need to migrate your data to other storage media. This mode meets the data analysis requirements of the finance and Internet industries.
  • Optimizes high-throughput writes and high-performance batch processing operations with elastic scaling to suit the scenarios in which large amounts of data and large traffic fluctuations are involved.
  • Provides the data sharing feature based on the separation of storage and computing resources. Shared data can be accessed from other databases without the need of data export and import. It is easier and more cost-effective than data access in traditional data warehouses.

Precautions

Notice On the International site (alibabacloud.com), AnalyticDB for PostgreSQL instances in Serverless mode can be created only on a pay-as-you-go basis.

AnalyticDB for PostgreSQL in Serverless mode is supported in the following regions and zones:

  • China
    • China (Beijing): Zone H and Zone I
    • China (Hangzhou): Zone I and Zone J
    • China (Shanghai): Zone G and Zone F
    • China (Zhangjiakou): Zone C
    • China (Shenzhen): Zone E and Zone F
  • Asia Pacific

    Singapore (Singapore): Zone A and Zone C

  • Europe & Americas

    US (Virginia): Zone A

Comparison of service modes

The Serverless mode supports most features of the elastic storage mode. The following table describes the differences between these two service modes.

Category Feature Elastic storage mode Serverless mode
Instance management Basic instance information Supported Supported
Logon to databases by using Data Management (DMS) Supported Supported
Instance creation Supported Supported
Instance release Supported Supported
Instance restart Supported Supported
Instance configuration upgrade or downgrade Supported Not supported
Coordinator node addition or removal Supported Supported
Instance scale-out Supported Supported
Instance scale-in Not supported Supported
Minor version update Supported Supported
Account management Account creation Supported Supported
Password resetting Supported Supported
Database connection Basic connection information Supported Supported
Public endpoint application Supported Supported
Monitoring and alerting Monitoring Supported Supported
Alert rules Supported Supported
Data security Whitelists Supported Supported
SQL audit Supported Supported
SSL encryption Supported Supported
Backup and restoration Supported Supported
Configuration Parameter settings Supported Supported

Limits

The Serverless mode supports more than 95% of features of the elastic storage mode. In most cases, the same syntax can be used for both the Serverless and elastic storage modes. Tools such as the JDBC connector, ODBC connector, and psql can be used in Serverless mode in the same way as they are used in elastic storage mode. The following table describes the limits of AnalyticDB for PostgreSQL in Serverless mode on specific features.

Category Feature Description
Basic features ALTER TABLE
  • Most features of ALTER TABLE are supported. For example, you can modify the table name, delete column constraints, and add or remove columns.
  • The data type of columns or the distribution column cannot be modified.
Indexes Not supported
Primary keys Not supported
Unique constraints Not supported
INSERT ON CONFLICT Not supported
Table unlogging Not supported
Triggers Not supported
Heap tables, append-optimized row-oriented tables, and append-optimized column-oriented tables Not supported
Custom data types Not supported
Explicit cursors Supported
Compute engines ORCA optimizer Supported
Laser engine Supported
Transaction capabilities Subtransactions Supported
Transaction isolation levels Read Committed and Repeatable Read are supported.
Advanced features Backup and restoration Supported
Materialized views Supported
Auto-vacuum Supported
Auto-analyze Supported
Elastic scale-out Supported
Elastic scale-in Supported
GIS/Ganos Not supported
Data sharing Supported

Data migration

You can migrate data from an AnalyticDB for PostgreSQL instance in elastic or reserved storage mode to an instance in Serverless mode. For more information, see Migrate data from an AnalyticDB for PostgreSQL instance in elastic or reserved storage mode to an instance in Serverless mode.

The following table describes the support of the Serverless mode for different data migration types.

Migration type References Description
Write data Use INSERT ON CONFLICT to overwrite data Not supported
Use COPY ON CONFLICT to overwrite data Not supported
Use the Client SDK Supported
Migrate table data Use Data Integration to migrate and batch synchronize data Supported
Synchronize data from cloud databases Not supported
Synchronize data from self-managed databases Not supported
Use a Realtime Compute for Apache Flink cluster to write data to an AnalyticDB for PostgreSQL instance Not supported

You can import data by using external tables.

Use the \copy command to import data from your computer to AnalyticDB for PostgreSQL Supported
Use an external table to import data from OSS at a high speed Supported
Use an external table to read and write HDFS data Supported
Migrate warehouse data Migrate data from a self-managed Greenplum cluster to an AnalyticDB for PostgreSQL instance Not supported

You can import data by using external tables.

Migrate data from a Teradata database to an AnalyticDB for PostgreSQL instance Not supported

You can import data by using external tables.

Migrate data from an Amazon Redshift instance to an AnalyticDB for PostgreSQL instance Not supported

You can import data by using external tables.

Migrate data from a self-managed Oracle application to an AnalyticDB for PostgreSQL instance Not supported

You can import data by using external tables.

Migrate data from a self-managed Oracle database to an AnalyticDB for PostgreSQL instance Not supported

You can import data by using external tables.

Elastic scaling

Instances in Serverless mode can be scaled within minutes. The following scaling performance is provided for reference:

  • An instance that has 16 or fewer compute nodes can be scaled within 60 seconds.
  • An instance that has more than 16 compute nodes can be scaled within 5 minutes.

You can use the elastic scaling capability of AnalyticDB for PostgreSQL in Serverless mode to scale out compute nodes before expected peak periods such as Double 11 and then scale in compute nodes after the peak hours. AnalyticDB for PostgreSQL is billed on an hourly basis based on the actual duration of resource use and compute node specifications. This way, you can minimize costs while ensuring the service performance.

In Serverless mode, each compute node has a maximum storage capacity. Before you scale in compute nodes, make sure that the total amount of data does not exceed the maximum storage capacity of all the remaining compute nodes combined. For example, assume that each compute node provides 2 cores, 8 GB memory, and a maximum of 960 GB storage capacity. If you want to scale in your instance to four compute nodes, the total amount of data cannot exceed 3,840 GB (960 GB × 4).

The following table describes the maximum storage capacity of different compute node specifications in AnalyticDB for PostgreSQL in Serverless mode.

Specifications Maximum storage capacity
2 cores, 8 GB memory 960 GB
4 cores, 16 GB memory 2,200 GB
8 cores, 32 GB memory 5,400 GB
16 cores, 64 GB memory 11,800 GB

Except during service interruptions that occur before and after scaling, workloads remain readable and writable during the scaling process.

Data sharing (beta)

Compared with the data import and export method used in traditional data warehouses, data sharing used in AnalyticDB for PostgreSQL in Serverless mode has the following advantages:

  • Reduced storage costs: Data replication or migration is not needed across AnalyticDB for PostgreSQL instances. Only a single copy of data is stored in the distributed storage and can be shared by multiple instances within the specified range. This way, less storage space is required.
  • Ease of use: After you create a share on a producer instance, perform authorization, and then import data to the share, you can access the shared data on a consumer instance in the same manner as you would access data on the producer instance. The table schema does not need to be migrated. The addition or removal of shared objects and authorization changes can be automatically synchronized to the consumer instance.
  • Data consistency: Consumer instances can access the shared data with capabilities approximate to those of producer instances. In addition, consumer instances can read the latest written data of producer instances. This ensures the atomicity, consistency, isolation, durability (ACID) capabilities of transactions.

Data sharing can help you resolve the following issues:

  • Isolation between complex organization permissions: For example, assume that an instance is created in the corporate headquarters and another instance is created in a branch. Data sharing can be used to allow the instance in the branch to access specific data of the instance in the corporate headquarters.
  • Isolation between complex business resources: For example, assume that physical resources are isolated between the extract, transform, load (ETL) and ad hoc business types. Data sharing can be used to share ETL results among instances that involve ad hoc queries.
  • Failure on cross-business collaboration: For example, if the same copy of data needs to be analyzed by R&D, sales, operations, and financial personnel, data sharing can be used to allow data access by different business groups within an organization.

Data sharing is in beta testing and has the following limits:

  • Data sharing is supported on standard tables. It is not supported on partitioned tables, external tables, views, schemas, or functions.
  • Data sharing is supported on hash distributed tables. It is not supported on replicated tables or random tables.
  • Data sharing is not supported on subtransactions.
  • If multiple shares exist in a producer instance, a consumer instance can subscribe only to one of the shares.
  • DDL operations are not allowed on shared tables. To perform DDL operations on a shared table, you must disable sharing for the table.

References