PolarDB:Performance testing report

Environment configuration

Benchmark tool

• Tool: YCSB (Yahoo! Cloud Serving Benchmark)

• Metric: OPS — the number of operations the database processes per second

Workload model

All workloads use YCSB CoreWorkload. The test data model uses records that each contain 10 fields, with each field value at 100 bytes, making each record approximately 1 KB.

Prerequisites

Before you begin, make sure you have:

• A PolarDB for PostgreSQL cluster (Enterprise Edition, Dedicated 16-core 64 GB)

• An ECS instance (16-core 64 GB, Alibaba Cloud Linux 3.2104 LTS 64-bit) in the same region as the cluster

• A dedicated DynamoDB account created in the PolarDB console — see Create a dedicated DynamoDB account and Configure a DynamoDB endpoint

• YCSB downloaded and built on the ECS instance

Step 1: Configure YCSB

Configure identity credentials

Edit dynamodb/conf/AWSCredentials.properties and enter the credentials for your dedicated DynamoDB account:

# The account name is the AccessKey ID
accessKey = <YOUR_ACCESS_KEY_ID>

# Secret key
secretKey = <YOUR_SECRET_ACCESS_KEY>

Configure connection properties

Edit dynamodb/conf/dynamodb.properties and specify the PolarDB cluster connection:

# The absolute path of the authentication file
dynamodb.awsCredentialsFile = /path/to/your/AWSCredentials.properties

# Create a usertable table in the cluster in advance.
# This example creates a usertable table with only a partition key named pk.
dynamodb.primaryKey = pk

# The DynamoDB endpoint for PolarDB. Must include the http:// prefix.
dynamodb.endpoint = http://<your-polardb-ddb-endpoint>:<port>

# Leave the region parameter blank.
dynamodb.region =

# The primary key name and type for the test table. Must match the test table.
dynamodb.primaryKey = HASH

Step 2: Patch the YCSB update operation

File to modify: dynamodb/src/main/java/site/ycsb/db/DynamoDBClient.java Method to modify: update()

Replace the original implementation:

@Override
public Status update(String table, String key, Map<String, ByteIterator> values) {
  if (LOGGER.isDebugEnabled()) {
    LOGGER.debug("updatekey: " + key + " from table: " + table);
  }

  Map<String, AttributeValueUpdate> attributes = new HashMap<>(values.size());
  for (Entry<String, ByteIterator> val : values.entrySet()) {
    AttributeValue v = new AttributeValue(val.getValue().toString());
    attributes.put(val.getKey(), new AttributeValueUpdate().withValue(v).withAction("PUT"));
  }

  UpdateItemRequest req = new UpdateItemRequest(table, createPrimaryKey(key), attributes);

  try {
    dynamoDB.updateItem(req);
  } catch (AmazonServiceException ex) {
    LOGGER.error(ex);
    return Status.ERROR;
  } catch (AmazonClientException ex) {
    LOGGER.error(ex);
    return CLIENT_ERROR;
  }
  return Status.OK;
}

With the UpdateExpression-based implementation:

@Override
public Status update(String table, String key, Map<String, ByteIterator> values) {
  if (LOGGER.isDebugEnabled()) {
    LOGGER.debug("updatekey: " + key + " from table: " + table);
  }

  StringBuilder updateExp = new StringBuilder("SET ");
  Map<String, String> attrNames = new HashMap<>();
  Map<String, AttributeValue> attrValues = new HashMap<>();
  boolean first = true;
  for (Map.Entry<String, ByteIterator> entry : values.entrySet()) {
    String attr = entry.getKey();
    if (!first) {
      updateExp.append(", ");
    }
    String attrName = "#" + attr;
    String valueName = ":" + attr;
    updateExp.append(attrName).append(" = ").append(valueName);
    attrNames.put(attrName, attr);
    attrValues.put(valueName, new AttributeValue(entry.getValue().toString()));
    first = false;
  }

  UpdateItemRequest req = new UpdateItemRequest()
      .withTableName(table)
      .withKey(createPrimaryKey(key))
      .withUpdateExpression(updateExp.toString())
      .withExpressionAttributeNames(attrNames)
      .withExpressionAttributeValues(attrValues);

  try {
    dynamoDB.updateItem(req);
  } catch (AmazonServiceException ex) {
    LOGGER.error(ex);
    return Status.ERROR;
  } catch (AmazonClientException ex) {
    LOGGER.error(ex);
    return CLIENT_ERROR;
  }
  return Status.OK;
}

Step 3: Run the test

Each test run has two phases: Load Phase (populate test data) and Run Phase (execute the workload). The examples below use a 1 GB dataset (1 million records), 128 concurrent threads, and the read-only workload.

To test different data volumes, adjust the recordcount and operationcount parameters.

Load Phase — populate test data

# -s: Displays status updates during loading.
# -P workloads/workload_read_only: Specifies the workload file.
# -P /path/to/dynamodb.properties: Specifies the database connection configuration.
# -p recordcount=1000000: Total number of records to load (1 GB).
# -p operationcount=1000000: Total number of operations.
# -threads 128: Number of concurrent threads.

nohup ./bin/ycsb load dynamodb -s \
  -P workloads/workload_read_only \
  -P /path/to/dynamodb.properties \
  -p recordcount=1000000 \
  -p operationcount=1000000 \
  -threads 128 \
  > load.log 2>&1 &

Run Phase — execute the workload

After loading completes, run the workload:

nohup ./bin/ycsb run dynamodb -s \
  -P workloads/workload_read_only \
  -P /path/to/dynamodb.properties \
  -p recordcount=1000000 \
  -p operationcount=1000000 \
  -threads 128 \
  > run.log 2>&1 &

Read the results

When the Run Phase completes, run.log contains a summary block at the end. The key metric is Throughput(ops/sec) under [OVERALL]. To find the peak OPS, run the same workload at different concurrency levels and compare the throughput values.

If you reproduce the tests with the same environment configuration, your peak throughput should be comparable to the values in the Test result summary table. Significant deviations may indicate resource contention, network latency, or a configuration mismatch — verify your cluster specifications, client placement, and connection settings.