Merge pull request #2291 from madeline-underwood/mongoDB

Mongo db_PV to sign off

Author: pareenaverma

content/learning-paths/servers-and-cloud-computing/mongodb-on-gcp/_index.md

@@ -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
 

content/learning-paths/servers-and-cloud-computing/mongodb-on-gcp/background.md

@@ -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/).

content/learning-paths/servers-and-cloud-computing/mongodb-on-gcp/baseline-testing.md

@@ -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:
 
@@ -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:
 
@@ -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:
@@ -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:
 
@@ -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:
 
@@ -89,7 +94,7 @@ Expected output:
 }
 ```
 
-### 6. View the Updated Document
+## View the updated document
 
 Confirm that the document was updated:
 
@@ -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 })
@@ -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:
 
@@ -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:
 
@@ -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()
@@ -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.

content/learning-paths/servers-and-cloud-computing/mongodb-on-gcp/benchmarking.md

@@ -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 \
@@ -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
@@ -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.

content/learning-paths/servers-and-cloud-computing/mongodb-on-gcp/create-instance.md

@@ -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.