Serverless mode

Introduction

AnalyticDB for PostgreSQL Serverless mode, with its cloud-native architecture, completely decouples computing from storage, addressing the issue of proportional scaling. It enables users to scale computing power quickly and independently during business fluctuations, while storage costs are based on a pay-as-you-go model. This flexibility allows for rapid adaptation to business changes and cost optimization, helping enterprises to reduce expenses and enhance efficiency.

Serverless mode offers several advantages over the elastic storage mode:

• It significantly reduces storage costs and supports on-demand usage. Historical data does not need to be migrated to other storage media, simplifying data analysis and providing a cost-effective, efficient one-stop solution for the growing data analysis needs of industries such as finance and the Internet.

• It optimizes high-throughput write scenarios and high-performance batch processing operations, offering elastic scaling capabilities suitable for large business data volumes and typical business access peaks and troughs.

• It enables data sharing based on compute-storage separation, transcending the limitations of physical machines and facilitating data flow in the cloud. The one-write-multiple-read model eliminates the need for data import before access in traditional data warehouses, streamlining operations, enhancing efficiency, and reducing costs.

Precautions

Comparison of service modes

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

Features and constraints

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

Data migration

You can migrate existing data to the serverless pattern. For migrating AnalyticDB for PostgreSQL from the elastic storage pattern and reserved storage pattern to the serverless pattern, see data migration between AnalyticDB for PostgreSQL.

For more information about data migration support, see the following table.

Automatic scheduling (in invitational preview)

AnalyticDB for PostgreSQL Serverless automatic scheduling mode instances will automatically start and stop based on traffic awareness. If there is no traffic, the instance will automatically enter an idle state, during which no computing fees will be charged.

AnalyticDB for PostgreSQL Serverless automatic scheduling mode allows you to manually modify the Computing Resource Threshold and Idle Release Waiting Time. For more information, see 实例资源配置.

Serverless automatic scheduling mode instances are billed based on Analytic Compute Units (ACUs), which are the computing power units of Serverless automatic scheduling mode instances. Alibaba Cloud collects the number of used ACUs every hour and bills on a per-second basis, with hourly billing. For more pricing information, see 产品定价.

Elastic scaling

Serverless mode supports minute-level online elastic scaling. The following scaling performance is provided for reference:

• Up to 60 seconds are required to scale an instance with 16 or fewer nodes.

• An instance with 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. The billing module of AnalyticDB for PostgreSQL will charge based on the actual application duration and specifications (on an hourly basis). 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, ensure that the total data volume does not exceed the maximum storage capacity of all the remaining compute nodes combined. For example, if each compute node provides 2 CPU cores, 8 GB of memory, and a maximum of 960 GB storage capacity, and you want to scale in your instance to four compute nodes, your total data volume 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.

During the scaling process, the workloads arestill readable and writable, except for brief service interruptions before and after scaling.

Data sharing (beta)

Data sharing in AnalyticDB for PostgreSQL Serverless mode offers several advantages over traditional data import and export methods:

• Storage costs are reduced as there is no need to copy or move data between multiple AnalyticDB for PostgreSQL instances. A single copy of data is stored in distributed storage and can be shared by multiple instances within the specified range, requiring less storage space.

• Ease of use is enhanced because once a share is created on a producer instance and data is imported after authorization, the shared data can be accessed on a consumer instance just as on the producer instance without needing to migrate the table schema. Shared objects and authorization changes are automatically synchronized to the consumer instance.

• Data consistency is maintained as consumer instances can access the shared data with capabilities similar to those of producer instances. Additionally, consumer instances can read the latest data written by producer instances, ensuring the atomicity, consistency, isolation, and durability (ACID) of transactions.

Data sharing can address the following challenges:

• Isolation between complex organizational permissions: For instance, an instance at the corporate headquarters and another at a branch can use data sharing to allow the branch instance to access specific data from the headquarters instance.

• Isolation between complex business resources: Physical resources can be isolated between ETL and ad hoc business types, and data sharing can be used to share ETL results among instances involved in ad hoc queries.

• Challenges in cross-business collaboration: If the same data set needs to be analyzed by R&D, sales, operations, and finance teams, data sharing allows different business groups within an organization to access the data.

Data sharing is currently in beta testing and has the following limitations:

• Data sharing is supported for standard tables but not for partitioned tables, external tables, views, schemas, or functions.

• Data sharing is supported for hash distributed tables but not for replicated tables or random tables.

• Data sharing is not supported for subtransactions.

• If multiple shares exist in a producer instance, a consumer instance can subscribe to only one of the shares at a time.

• DDL operations are not permitted on shared tables. To perform DDL operations on a shared table, sharing must be disabled first.

References

• 【通知】AnalyticDB PostgreSQL版发布Serverless模式

• Quick Start

• AnalyticDB PostgreSQL版间的数据迁移

• Serverless模式导入和查询数据性能测试

• Data sharing