AnalyticDB for PostgreSQL Basic Edition uses a single-replica architecture that reduces costs for storage and entry-level instances and enables high I/O performance.
The coordinator nodes and compute nodes of AnalyticDB for PostgreSQL Basic Edition instances are deployed in a single-replica architecture, as shown in the following figure.
Compared with the High-availability Edition architecture, the Basic Edition architecture does not contain the standby coordinator node or secondary compute nodes.
The Basic Edition architecture has the following benefits:
- The storage usage of the standby coordinator node is eliminated.
- The storage usage of compute nodes is reduced by half.
- The data synchronization process between the primary and secondary compute nodes is eliminated, which improves the I/O performance when data is written.
For more information, see AnalyticDB for PostgreSQL Pricing.
- Cost reduction
Compared with a High-availability Edition instance, a Basic Edition instance with the same specifications provides the following cost advantages:
- The storage cost is reduced by 50% because the instance has one less replica.
- Compute nodes cost less but deliver the same computing power.
Specifications Storage pricing Compute node pricing Instance pricing Basic Edition High-availability Edition Reduced by Basic Edition High-availability Edition Reduced by Basic Edition High-availability Edition Reduced by Entry-level specifications USD 22.4/month USD 100/month 77.6% USD 175.55/month USD 352.05/month 50.13% USD 197.95/month USD 452.05/month 56.21% Common specifications USD 89.6/month USD 200/month 55.2% USD 668.65/month USD 700.28/month 4.52% USD 758.25/month USD 900.28/month 15.78%
- A Basic Edition instance with entry-level specifications has 2 CPU cores, 50 GB of storage space, and 2 compute nodes. A High-availability Edition instance with entry-level specifications has 2 CPU cores, 50 GB of storage space, and 4 compute nodes. These are the minimum specifications for AnalyticDB for PostgreSQL instances. For entry-level specifications, the price of a Basic Edition instance is 56% lower than that of a High-availability Edition instance.
- In common scenarios, an AnalyticDB for PostgreSQL instance has 4 CPU cores, 100 GB of storage space, and 4 compute nodes for both Basic Edition and High-availability Edition. In these scenarios, the price of a Basic Edition instance is 15% lower than that of a High-availability Edition with the same specifications.
- Performance improvement
Basic Edition delivers significantly better I/O performance than High-availability Edition. A Basic Edition instance with 2 CPU cores delivers up to 250% higher I/O performance than a High-availability Edition instance with the same specifications. The data synchronization and streaming replication processes are eliminated in Basic Edition. This allows an additional 100% I/O performance improvement in write-intensive scenarios.
In the following examples, the performance advantages of Basic Edition over High-availability Edition are demonstrated in local replication and TPC-H test scenarios. An instance of each edition is used, and both instances have 2 CPU cores, 400 GB of storage space, and 4 compute nodes.
- Local replication
A row-oriented table with about 90 GB of data is replicated within the instance. The following statement is executed:
create table lineitem2 as (select * from lineitem);
It takes 249 seconds for the Basic Edition instance to complete the operation but 1,307 seconds for the High-availability Edition instance, which is nearly a five-time performance improvement.
The test shows that Basic Edition provides significantly better performance in I/O-intensive scenarios, such as CTAS and INSERT INTO SELECT operations.
- TPC-H testing
Note In this example, a test based on the TPC-H benchmark test is implemented, but it does not meet all the requirements of the TPC-H benchmark test. Therefore, the test results cannot be compared with the published results of the TPC-H benchmark test.
In this test, 22 SQL statements are executed on a TPC-H test dataset that contains 100 GB of data. The following figure shows the results.
The time consumed by the Basic Edition instance is 40% less than the High-availability instance, which demonstrates the I/O performance improvement.
- Local replication
- Data reliability
Enhanced SSDs (ESSDs) are used by AnalyticDB for PostgreSQL to store data. They provide high data reliability even in single-replica mode and ensure data integrity when faults occur on compute nodes.
- High availability
AnalyticDB for PostgreSQL Basic Edition delivers lower availability due to the reduction of a replica. This increases the amount of time required to recover instances in severe scenarios, such as physical machine failures. Basic Edition uses the multi-replica feature of ESSDs to ensure data reliability. The checkpoint mechanism of PostgreSQL is optimized to reduce recovery time for AnalyticDB for PostgreSQL instances.
The following section compares the availability of Basic Edition and High-availability Edition instances in common failure scenarios:
- Failures that trigger the recovery mode
In most failure scenarios in AnalyticDB for PostgreSQL, the recovery mode is triggered. The recovery process takes a significantly less amount of time for Basic Edition than for High-availability Edition.
Most SQL crashes are caused by core dumps or out of memory (OOM) errors. In this case, the AnalyticDB for PostgreSQL instance enters the recovery mode. In recovery mode, the system clears the remaining locks and memory and replays the Write Ahead Log (WAL) files to ensure data integrity. Service provision stops on the instance during the recovery process and resumes after the instance is recovered. A High-availability Edition instance may require 5 to 10 minutes to be recovered, while a Basic Edition instance can be recovered within 10 seconds by using the optimized checkpoint mechanism.
In AnalyticDB for PostgreSQL, all data changes of a transaction are first recorded in WAL files before the transaction is committed. When a database restores data, WAL files can be replayed to restore the data changes that are committed but not written to the disk.
A checkpoint marks the point in a transaction before which all data changes have been made on the disk. The database can restore data based on the latest checkpoint. AnalyticDB for PostgreSQL performs checkpoints on a regular basis. When a WAL file reaches a specific length, the system also performs checkpoints.
- Compute node failures
Basic Edition instances provide lower availability when a compute node fails. When faults occur on a compute node of a High-availability Edition instance, the replica seamlessly takes over to ensure service availability, and the faulty compute node becomes the secondary compute node and restarts in the backend. However, when faults occur on a compute node of a Basic Edition instance, the lack of a replica renders the instance unavailable, and the instance must be restarted for recovery.
- Host failures
Host failures are severe situations and trigger automatic migration of the host. Even in such scenarios, the replica of a High-availability Edition instance can still take over and ensure the normal running of the instance. The host migration is performed in the backend. However, a Basic Edition instance must be restarted after the host migration is complete. The process may take 15 minutes.
- Failures that trigger the recovery mode