Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
@@ -1,21 +1,17 @@
---
title: Deploy MongoDB on Google Axion C4A virtual machine
title: Deploy MongoDB on an Arm-based Google Axion C4A VM

minutes_to_complete: 15

draft: true
cascade:
draft: true

who_is_this_for: This is an introductory topic for software developers looking to migrate their MongoDB workloads from x86_64 to Arm-based platforms, specifically on Google Axion-based C4A virtual machines.
who_is_this_for: This introductory topic is for software developers who want to migrate MongoDB workloads from x86_64 to Arm-based platforms, specifically on Google Axion-based C4A virtual machines.

learning_objectives:
- Create an Arm cloud instance on the Google Cloud Platform
- Install and run MongoDB on the Arm-based GCP C4A instance.
- Benchmark the MongoDB performance on Arm using Yahoo Cloud Serving Benchmark (YCSB).
- Create an Arm virtual machine on Google Cloud (C4A Axion family)
- Install and run MongoDB on the Arm-based C4A instance
- Benchmark MongoDB performance with Yahoo Cloud Serving Benchmark (YCSB)

prerequisites:
- A [Google Cloud Platform (GCP)](https://cloud.google.com/free?utm_source=google&hl=en) account with billing enabled.
- A [Google Cloud Platform (GCP)](https://cloud.google.com/free?utm_source=google&hl=en) account with billing enabled

author: Annie Tallund

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -8,15 +8,14 @@ layout: "learningpathall"

## Google Axion C4A series

The C4A series is a family of Arm-based instance types for Google’s custom Axion CPU, which is based on Arm Neoverse-V2 cores. Designed for high-performance and energy-efficient computing, these virtual machine offer strong performance suitable for modern cloud workloads such as CI/CD pipelines, microservices, media processing, and general-purpose applications.
The C4A series is a family of Arm-based instance types for Google’s custom Axion CPU, which is based on Arm Neoverse-V2 cores. Designed for high performance and energy-efficient computing, these virtual machine offer strong performance suitable for modern cloud workloads such as CI/CD pipelines, microservices, media processing, and general-purpose applications.

The C4A series provides a cost-effective virtual machine while leveraging the scalability and performance benefits of the Arm architecture in Google Cloud.

To learn more about Google Axion, refer to the blog [Introducing Google Axion Processors, our new Arm-based CPUs](https://cloud.google.com/blog/products/compute/introducing-googles-new-arm-based-cpu).
To learn more about Google Axion, see the blog post [Introducing Google Axion Processors, our new Arm-based CPUs](https://cloud.google.com/blog/products/compute/introducing-googles-new-arm-based-cpu).

## MongoDB
MongoDB is a popular open-source NoSQL database designed for high performance, scalability, and flexibility.

It stores data in JSON-like BSON documents, making it ideal for modern applications that require dynamic, schema-less data structures.
MongoDB is a popular open-source NoSQL database designed for performance, scalability, and flexibility. It stores data in JSON-like BSON documents, making it well suited to applications that require dynamic, schema-less data models.

MongoDB is widely used for web, mobile, IoT, and real-time analytics workloads. Learn more from the [MongoDB official website](https://www.mongodb.com/) and its [official documentation](https://www.mongodb.com/docs/).
MongoDB is widely used for web, mobile, IoT, and real-time analytics workloads. Learn more on the [MongoDB website](https://www.mongodb.com/) and in the [MongoDB documentation](https://www.mongodb.com/docs/).
Original file line number Diff line number Diff line change
Expand Up @@ -6,17 +6,22 @@ weight: 5
layout: learningpathall
---

Now that MongoDB is successfully installed on your GCP C4A Arm virtual machine, follow these steps to verify that the server is running correctly and accepting local connections.
## Overview

### 1. Connect to MongoDB
Now that MongoDB is installed on your Google Axion C4A Arm VM, verify that the server is running and accepting local connections.

Use mongosh to create a test database, run basic CRUD operations, and capture a quick insert-time baseline before you start benchmarking.

## Connect to MongoDB

Open a shell session to the local MongoDB instance:

```console
mongosh mongodb://127.0.0.1:27017
```

### 2. Create a Test Database and Collection

## Create a test database and collection

Switch to a new database and create a collection:

Expand All @@ -34,7 +39,7 @@ switched to db baselineDB
{ ok: 1 }
```

### 3. Insert 10,000 Test Documents
## Insert 10,000 test documents

Populate the collection with 10,000 timestamped documents:

Expand All @@ -48,9 +53,9 @@ for (let i = 0; i < 10000; i++) {
}
```

Each document will contain:
Each document contains:
- `record`: a counter from 0 to 9999
- `status`: always `"new"`
- `status`: `"new"`
- `timestamp`: the current date/time of insertion

Sample output:
Expand All @@ -59,7 +64,7 @@ Sample output:
{ acknowledged: true, insertedId: ObjectId('...') }
```

### 4. Read a Subset of Documents
## Read a subset of documents

Verify read functionality by querying the first few documents:

Expand All @@ -69,7 +74,7 @@ db.test.find({ status: "new" }).limit(5)

This returns the first 5 documents where `status` is `"new"`.

### 5. Update a Document
## Update a document

Update a specific document by changing its status:

Expand All @@ -89,7 +94,7 @@ Expected output:
}
```

### 6. View the Updated Document
## View the updated document

Confirm that the document was updated:

Expand All @@ -108,15 +113,15 @@ Expected output:
}
```

### 7. Delete a Document
## Delete a document

The command below tells MongoDB to delete one document from the test collection, where record is exactly 100:

```javascript
db.test.deleteOne({ record: 100 })
```

Verify that it was deleted:
Verify deletion:

```javascript
db.test.findOne({ record: 100 })
Expand All @@ -128,7 +133,7 @@ Expected output:
null
```

### 8. Measure Execution Time (Optional)
## Measure execution time (optional)

Measure how long it takes to insert 10,000 documents:

Expand All @@ -146,7 +151,7 @@ Sample output:
Insert duration (ms): 4427
```

### 9. Count Total Documents
## Count total documents

Check the total number of documents in the collection:

Expand All @@ -163,9 +168,11 @@ Expected output:
The count **19999** reflects the total documents after inserting 10,000 initial records, adding 10,000 more (in point 8), and deleting one (record: 100).


### 10. Clean Up (Optional)
## Clean up (optional)

For the sake of resetting the environment, this following command deletes the current database you are connected to in mongosh.

For the sake of resetting the environment, this following command deletes the current database you are connected to in mongosh. Drop the `baselineDB` database to remove all test data:
Drop the `baselineDB` database to remove all test data:

```javascript
db.dropDatabase()
Expand All @@ -177,4 +184,4 @@ Expected output:
{ ok: 1, dropped: 'baselineDB' }
```

These baseline operations confirm that MongoDB is functioning properly on your GCP Arm64 environment. Using `mongosh`, you validated key database capabilities including **inserts**, **queries**, **updates**, **deletes**, and **performance metrics**. Your instance is now ready for benchmarking or application integration.
These baseline operations confirm that MongoDB is functioning properly on your GCP Arm64 environment. Using `mongosh`, you validated inserts, queries, updates, deletes, and basic performance timing. Your instance is now ready for benchmarking or application integration.
Original file line number Diff line number Diff line change
Expand Up @@ -5,36 +5,36 @@ weight: 6
### FIXED, DO NOT MODIFY
layout: learningpathall
---
## MongoDB Benchmarking with YCSB (Yahoo! Cloud Serving Benchmark)

**YCSB (Yahoo! Cloud Serving Benchmark)** is an open-source tool for evaluating the performance of NoSQL databases under various workloads. It simulates operations such as reads, writes, updates, and scans to mimic real-world usage patterns.
## Benchmark MongoDB with YCSB

### Install YCSB (Build from Source)
YCSB (Yahoo! Cloud Serving Benchmark) is an open-source tool for evaluating NoSQL databases under various workloads. It simulates operations such as writes, updates, and scans to mimic production traffic.

First, install the required build tools and clone the YCSB repository:
## Install YCSB from source

Install build tools and clone YCSB, then build the MongoDB binding:

```console
sudo dnf install -y git maven java-11-openjdk-devel
git clone https://github.com/brianfrankcooper/YCSB.git
cd YCSB
mvn -pl site.ycsb:mongodb-binding -am clean package
```

### Load Phase – Insert Initial Dataset

This phase inserts a set of documents into MongoDB to simulate a typical starting workload. By default, it inserts 1,000 records.
## Load initial data

Load a starter dataset (defaults to 1,000 records) into MongoDB:
```console
./bin/ycsb load mongodb -s \
-P workloads/workloada \
-p mongodb.url=mongodb://127.0.0.1:27017/ycsb
```

This prepares the database for the actual performance test.
This prepares the database for the performance test.

### Execute Benchmark Workload
## Run a mixed workload

Run the actual benchmark with the predefined workload. This command performs mixed read/write operations and collects performance metrics.
Run Workload A (50% reads, 50% updates) and collect metrics:

```console
./bin/ycsb run mongodb -s \
Expand All @@ -48,7 +48,7 @@ Run the actual benchmark with the predefined workload. This command performs mix

This simulates common real-world applications like session stores or shopping carts.

You’ll see performance output that looks like this:
Sample output:

```output
[READ], Operations, 534
Expand All @@ -65,39 +65,41 @@ You’ll see performance output that looks like this:
[OVERALL], Throughput(ops/sec), 1953.125
```

### YCSB Operations & Latency Metrics Explained
## Understand YCSB metrics

- **Operations Count**: Total operations performed for each type (e.g., READ, UPDATE).
- **Operations Count**: Total operations performed for each type (for example, READ, UPDATE).
- **Average Latency (us)**: The average time to complete each operation, measured in microseconds.
- **Min Latency / Max Latency (us)**: The fastest and slowest observed times for any single operation of that type.

With YCSB installed and benchmark results captured, you now have a baseline for MongoDB's performance under mixed workloads.

### Benchmark summary on x86_64
## Benchmark summary on x86_64

To better understand how MongoDB behaves across architectures, YCSB benchmark workloads were run on both an **x86_64 (C3 Standard)** and an **Arm64 (C4A Standard)** virtual machine, each with 4 vCPUs and 16 GB of memory, running RHEL 9.

The following benchmark results are collected on a c3-standard-4 (4 vCPU, 2 core, 16 GB Memory) x86_64 environment, running RHEL 9.
Results from a c3-standard-4 instance (4 vCPUs, 16 GB RAM) on RHEL 9:

| Operation | Count | Avg Latency (us) | Min Latency (us) | Max Latency (us) | 50th Percentile (us) | 95th Percentile (us) | 99th Percentile (us) |
|-----------|-------|------------------|------------------|------------------|-----------------------|----------------------|-----------------------|
| READ | 472 | 672.27 | 177 | 56703 | 514 | 903 | 1331 |
| UPDATE | 528 | 621.27 | 214 | 12855 | 554 | 971 | 1224 |
| CLEANUP | 1 | 4702 | 4700 | 4703 | 4703 | 4703 | 4703 |

### Benchmark summary on Arm64:
The following benchmark results are collected on a c4a-standard-4 (4 vCPU, 16 GB Memory) Arm64 environment, running RHEL 9.
## Benchmark summary on Arm64 (Google Axion C4A):
Results from a c4a-standard-4 instance (4 vCPUs, 16 GB RAM) on RHEL 9:

| Operation | Count | Avg Latency (us) | Min Latency (us) | Max Latency (us) | 50th Percentile (us) | 95th Percentile (us) | 99th Percentile (us) |
|----------|------------------|------------------|------------------|------------------|----------------------|----------------------|----------------------|
| READ | 534 | 312.96 | 156 | 8279 | 261 | 524 | 758 |
| UPDATE | 466 | 384.45 | 186 | 26543 | 296 | 498 | 821 |
| CLEANUP | 1 | 4138 | 4136 | 4139 | 4139 | 4139 | 4139 |

### **Highlights from GCP C4A Arm virtual machine**
## Highlights from the C4A Arm VM

- Lower average latencies on Arm: ~313 µs (READ) and ~384 µs (UPDATE).

- Stable p50–p99 latencies indicate consistent performance.

- Arm results show low **average latencies**, **READ** at **313 us** and **UPDATE** at **384 us**.
- **50th** to **99th percentile** latencies remain stable, indicating consistent performance.
- **Max latency** spikes (**8279 us READ**, **26543 us UPDATE**) suggest rare outliers.
- Occasional max-latency outliers suggest transient spikes common in mixed workloads.

This Learning Path walked you through setting up and benchmarking MongoDB on an Arm-based GCP instance, highlighting how to run core operations, validate performance, and interpret benchmarking results with YCSB. Alongside, you explored some performance numbers, showing that Arm is a powerful and cost-efficient alternative for modern data-serving workloads like MongoDB.
With YCSB built and results captured, you now have a baseline for MongoDB performance on Arm-based Google Axion C4A. You can iterate on dataset size, thread counts, and workloads (A–F) to profile additional scenarios and compare cost-performance across architectures.
Original file line number Diff line number Diff line change
Expand Up @@ -6,28 +6,29 @@ weight: 3
layout: learningpathall
---

## Introduction
## Overview

This section walks you through creating a **Google Axion C4A Arm virtual machine** on GCP with the **c4a-standard-4 (4 vCPUs, 16 GB Memory)** machine type, using the **Google Cloud Console**.
This section walks you through creating a Google Axion C4A Arm virtual machine on GCP with the `c4a-standard-4` (4 vCPUs, 16 GB Memory) machine type, using the **Google Cloud Console**.

If you haven't set up a Google Cloud account, check out the Learning Path on [Getting Started with Google Cloud Platform](https://learn.arm.com/learning-paths/servers-and-cloud-computing/csp/google/).
If you haven't set up a Google Cloud account, see the Learning Path [Getting started with Google Cloud Platform](https://learn.arm.com/learning-paths/servers-and-cloud-computing/csp/google/).

### Create an Arm-based Virtual Machine (C4A)
## Create an Arm-based virtual machine (C4A)

To create a virtual machine based on the C4A Arm architecture:
1. Navigate to the [Google Cloud Console](https://console.cloud.google.com/).
2. Go to **Compute Engine** and click on **Create Instance**.
3. Under the **Machine Configuration**:
- Fill in basic details like **Instance Name**, **Region**, and **Zone**.
- Select the **Series** as `C4A`.
- Choose a machine type such as `c4a-standard-4`.
![Instance Screenshot](./select-instance.png)
4. Under the **OS and Storage**, click on **Change**, and select **Red Hat Enterprise Linux** as the Operating System with **Red Hat Enterprise Linux 9** as the Version. Make sure you pick the version of image for Arm.
5. Under **Networking**, enable **Allow HTTP traffic** to allow interacting for later steps in the Learning Path.
6. Click on **Create**, and the instance will launch.
To create a VM based on the C4A Arm architecture:

1. Open the [Google Cloud Console](https://console.cloud.google.com/).
2. Go to **Compute Engine** and select **Create instance**.
3. In **Machine configuration**:
- Enter the **Instance name**, **Region**, and **Zone**.
- Set **Series** to `C4A`.
- Choose a machine type such as `c4a-standard-4`.
![Screenshot of GCP Create instance page showing C4A series and c4a-standard-4 selected alt-text#center](./select-instance.png "Selecting the C4A series and c4a-standard-4 machine type")
4. In **OS and storage**, select **Change**, choose **Red Hat Enterprise Linux** as the operating system, and **Red Hat Enterprise Linux 9** as the version. Make sure you select the **Arm** image.
5. In **Networking**, enable **Allow HTTP traffic** so you can test services later in this Learning Path.
6. Select **Create** to launch the instance.

{{% notice Important %}}
Avoid enabling Allow HTTP traffic permanently, as it introduces a security vulnerability. Instead, configure access to allow only your own IP address for long-term use.
Do not leave **Allow HTTP traffic** enabled permanently. For long-term use, restrict access to only the IP addresses you need.
{{% /notice %}}

To access the Google Cloud Console, click the SSH button in your instance overview. This will open a command line interface (CLI), which you’ll use to run the remaining commands in this Learning Path. Continue to the next section to set up MongoDB on your instance.
To open a shell on the VM, select **SSH** in the instance details page. Use this terminal for the commands in the next sections, where you will install and configure MongoDB on your Axion C4A instance.
Loading