AnalyticDB:Serverless mode

Overview

In Serverless mode, AnalyticDB for PostgreSQL decouples computing and storage resources so that they can be scaled in 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.

Usage notes

Not all regions and zones support AnalyticDB for PostgreSQL instances in Serverless mode. If purchase is unavailable in the current region or zone, select another region or zone. Actual regions and zones that support AnalyticDB for PostgreSQL instances in Serverless mode on the buy page shall prevail.

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.

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 Java Database Connectivity (JDBC) connector, Open Database Connectivity (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.

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 between AnalyticDB for PostgreSQL instances.

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

Automatic scheduling (public preview)

AnalyticDB for PostgreSQL instances in Serverless automatic scheduling mode can be automatically paused and resumed based on traffic detection. If no traffic occurs, the instances automatically change to the idle state. You are not charged for computing resources when the instances are in the idle state.

AnalyticDB for PostgreSQL instances in Serverless automatic scheduling mode allow you to modify the values of Computing Resource Threshold and Wait Time for Idle Resource Release parameters. For more information, see Configure instance resources.

You are billed for the instances in Serverless automatic scheduling mode per second based on the AnalyticDB compute units (ACUs) that measure the computing power of instances. The system collects the number of used ACUs and generates bills on an hourly basis. For more information, see Pricing.

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.

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 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 from a consumer instance in the same manner as you 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

• [Notice] Serverless mode released for AnalyticDB for PostgreSQL

• Overview

• Migrate data between AnalyticDB for PostgreSQL instances

• Performance of the Serverless mode

• Data sharing