Merge pull request #2681 from madeline-underwood/cass

Cassandra_JA to sign off

Author: jasonrandrews

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

@@ -1,9 +1,5 @@
 ---
-title:  Deploy Cassandra on a Google Axion C4A virtual machine
-
-draft: true
-cascade:
-    draft: true
+title: Deploy Cassandra on a Google Axion C4A virtual machine
 
 minutes_to_complete: 30
 
@@ -18,7 +14,7 @@ learning_objectives:
 
 prerequisites:
   - A [Google Cloud Platform (GCP)](https://cloud.google.com/free) account with billing enabled
-  - Familiarity with Cassandra architecture, replication, and [Cassandra partitioning & event-driven I/O](https://cassandra.apache.org/doc/stable/cassandra/architecture/)
+  - Familiarity with Cassandra architecture, replication, and [Cassandra partitioning and event-driven I/O](https://cassandra.apache.org/doc/stable/cassandra/architecture/)
 
 author: Pareena Verma
 

content/learning-paths/servers-and-cloud-computing/cassandra-on-gcp/backgraound.md

@@ -0,0 +1,23 @@
+---
+title: Get started with Cassandra on Google Axion C4A
+
+weight: 2
+
+layout: "learningpathall"
+---
+
+## Explore Google Axion C4A Arm instances
+
+Google Axion C4A is a family of Arm-based virtual machines built on Google's custom Axion CPU, based on Arm Neoverse-V2 cores. These virtual machines deliver strong performance for modern cloud workloads such as CI/CD pipelines, microservices, media processing, and general-purpose applications.
+
+The C4A series provides a cost-effective alternative to x86 virtual machines while leveraging the scalability and performance benefits of Arm architecture in Google Cloud.
+
+To learn more about Google Axion, see the Google blog [Introducing Google Axion Processors, our new Arm-based CPUs](https://cloud.google.com/blog/products/compute/introducing-googles-new-arm-based-cpu).
+
+## Explore Cassandra
+
+Cassandra is a highly scalable, distributed NoSQL database designed to handle large amounts of data across many commodity servers without a single point of failure.
+
+It provides high availability, fault tolerance, and linear scalability, making it ideal for real-time big data applications and high-throughput workloads.
+
+Cassandra is widely used for time-series data, IoT applications, recommendation engines, and large-scale cloud services. To learn, see the [Cassandra website](https://cassandra.apache.org/) and the [Cassandra documentation](https://cassandra.apache.org/doc/latest/).

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

@@ -1,17 +1,14 @@
 ---
-title: Apache Cassandra baseline testing on Google Axion C4A Arm Virtual machine
+title: Test Cassandra baseline functionality
 weight: 5
 
 ### FIXED, DO NOT MODIFY
 layout: learningpathall
 ---
 
+## Overview
 
-Since Cassandra has been successfully installed on your GCP C4A Arm virtual machine, follow these steps to verify that it is running and functioning properly.
-
-## Baseline Testing for Apache Cassandra
-
-This guide helps verify the installation and perform baseline testing of **Apache Cassandra**.
+Now that Cassandra is installed on your GCP C4A Arm virtual machine, verify that it's running and functioning properly.
 
 ## Start Cassandra
 
@@ -21,20 +18,23 @@ Run Cassandra in the background:
 cassandra -R
 ```
 
-The `-R` flag allows Cassandra to run in the background as a daemon, so you can continue using the terminal. The first startup may take **30–60 seconds** as it initializes the necessary files and processes.
+The `-R` flag allows Cassandra to run in the background as a daemon. The first startup may take 30–60 seconds as it initializes.
 
 Check logs to ensure Cassandra started successfully:
 
 ```console
 tail -f ~/cassandra/logs/system.log
 ```
-Look for the message **"Startup complete"**, which indicates Cassandra is fully initialized.
 
-### Check Cassandra Status
+Look for the message "Startup complete", which indicates Cassandra is fully initialized.
+
+## Check Cassandra status
+
 ```console
 nodetool status
 ```
-You should see an output similar to:
+
+The output is similar to:
 
 ```output
 Datacenter: datacenter1
@@ -44,29 +44,34 @@ Status=Up/Down
 --  Address    Load        Tokens  Owns (effective)  Host ID                               Rack
 UN  127.0.0.1  162.51 KiB  16      100.0%            78774686-39f3-47e7-87c3-3abc4f02a835  rack1
 ```
-The `nodetool status` command displays the health and status of your Cassandra node(s). For a single-node setup, the output should indicate that the node is **Up (U)** and **Normal (N)**. This confirms that your Cassandra instance is running and ready to accept queries.
 
-### Connect with CQLSH (Cassandra Query Shell)
-**cqlsh** is the interactive command-line shell for Cassandra. It allows you to run Cassandra Query Language (CQL) commands to interact with your database, create keyspaces and tables, insert data, and perform queries.
+For a single-node setup, the output should indicate that the node is Up (U) and Normal (N), confirming that your Cassandra instance is running and ready to accept queries.
+
+## Connect with CQLSH
+
+`cqlsh` is the interactive command-line shell for Cassandra that allows you to run Cassandra Query Language (CQL) commands.
 
 ```console
 cqlsh
 ```
-You’ll enter the CQL (Cassandra Query Language) shell.
 
-### Create a Keyspace (like a database)
-A **keyspace** in Cassandra is similar to a database in SQL systems. Here, we create a simple keyspace `testks` with a **replication factor of 1**, meaning data will only be stored on one node (suitable for a single-node setup).
+You'll enter the CQL (Cassandra Query Language) shell.
+
+## Create a keyspace
+
+A keyspace in Cassandra is similar to a database in SQL systems. Create a simple keyspace `testks` with a replication factor of 1 (suitable for a single-node setup):
 
 ```sql
 CREATE KEYSPACE testks WITH replication = {'class':'SimpleStrategy','replication_factor' : 1};
 ```
-Check if created:
+
+Verify the keyspace was created:
 
 ```sql
 DESCRIBE KEYSPACES;
 ```
 
-You should see an output similar to:
+The output is similar to:
 
 ```output
 cqlsh> DESCRIBE KEYSPACES;
@@ -75,8 +80,9 @@ system       system_distributed  system_traces  system_virtual_schema
 system_auth  system_schema       system_views   testks
 ```
 
-### Create a Table
-Tables in Cassandra are used to store structured data. This step creates a `users` table with three columns: `id` (unique identifier), `name` (text), and `age` (integer). The `id` column is the primary key.
+## Create a table
+
+Create a `users` table with three columns:
 
 ```sql
 USE testks;
@@ -88,22 +94,24 @@ CREATE TABLE users (
 );
 ```
 
-### Insert Data
-We insert two sample rows into the `users` table. The `uuid()` function generates a unique identifier for each row, which ensures that every user entry has a unique primary key.
+## Insert data
+
+Insert two sample rows into the `users` table. The `uuid()` function generates a unique identifier for each row:
 
 ```sql
 INSERT INTO users (id, name, age) VALUES (uuid(), 'Alice', 30);
 INSERT INTO users (id, name, age) VALUES (uuid(), 'Bob', 25);
 ```
 
-### Query Data
-This command retrieves all rows from the `users` table. Successful retrieval confirms that data insertion works correctly and that queries return expected results.
+## Query data
+
+Retrieve all rows from the `users` table:
 
 ```sql
 SELECT * FROM users;
 ```
 
-You should see an output similar to:
+The output is similar to:
 
 ```output
  id                                   | age | name
@@ -114,6 +122,6 @@ You should see an output similar to:
 (2 rows)
 ```
 
-This baseline test verifies that Cassandra 5.0.5 is installed and running correctly on the VM. It confirms the node status, allows connection via `cqlsh`, and ensures basic operations like creating a keyspace, table, inserting, and querying data work as expected.
+This baseline test verifies that Cassandra 5.0.5 is installed and running correctly on the VM, confirming node status, CQLSH connectivity, and basic database operations.
 
-Please now press "Ctrl-D" to exit the Cassandra Query Shell. 
+Press `Ctrl-D` to exit the Cassandra Query Shell. 

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

@@ -1,32 +1,32 @@
 ---
-title: Cassandra Benchmarking
+title: Benchmark Cassandra performance
 weight: 6
 
 ### FIXED, DO NOT MODIFY
 layout: learningpathall
 ---
 
-## Cassandra Benchmarking by Cassandra-Stress
-Cassandra benchmarking can be performed using the built-in `cassandra-stress` tool, which helps measure database performance under different workloads such as write, read, and mixed operations.
+## Benchmark Cassandra with cassandra-stress
 
-### Steps for Cassandra Benchmarking with Cassandra-Stress
-**Verify cassandra-stress Installation:**
+You can perform Cassandra benchmarking using the built-in `cassandra-stress` tool, which measures database performance under different workloads such as write, read, and mixed operations.
 
-Cassandra comes with a built-in tool called **cassandra-stress** that is used for testing performance. It is usually located in the `tools/bin/` folder of your Cassandra installation. 
+## Verify cassandra-stress installation
+
+Cassandra comes with a built-in tool called `cassandra-stress` that is used for testing performance. It's located in the `tools/bin/` folder of your Cassandra installation.
 
 ```console
 ls ~/cassandra/tools/bin | grep cassandra-stress
 ```
-If you see cassandra-stress in the list, it means the tool is installed and ready to use.
 
-**Run the version check:**
+If you see `cassandra-stress` in the list, the tool is installed and ready to use.
 
-To make sure the tool works correctly, check its help options.
+Check the tool's help options to verify it works correctly:
 
 ```console
 ~/cassandra/tools/bin/cassandra-stress help
 ```
-You should see output similar to the following:
+
+The output is similar to:
 
 ```output
 Usage:      cassandra-stress <command> [options]
@@ -43,10 +43,10 @@ help                 : Print help for a command or option
 print                : Inspect the output of a distribution definition
 version              : Print the version of cassandra stress
 ```
-If the tool is working, you will see a list of commands and options that you can use to run benchmarks.
-This confirms that your setup is correct and you’re ready to start testing Cassandra’s performance.
 
-### Basic Write Test
+The list of commands and options confirms that your setup is correct and you're ready to start testing Cassandra's performance.
+
+## Run a basic write test
 Insert 10,000 rows with 50 concurrent threads using `cassandra-stress`:
 
 ```console
@@ -56,7 +56,7 @@ Insert 10,000 rows with 50 concurrent threads using `cassandra-stress`:
 - **n=10000** → Specifies the number of rows to insert during the benchmark test.  
 - **-rate threads=50** → Sets the number of concurrent worker threads simulating multiple clients writing to the cluster. 
 
-You should see output similar to the following:
+The output is similar to:
 
 ```output
 ******************** Stress Settings ********************
@@ -186,13 +186,16 @@ Total operation time      : 00:00:00
 END
 ```
 
-### Read Test
-The following command runs a **read benchmark** on your Cassandra database using `cassandra-stress`. It simulates multiple clients reading from the cluster at the same time and records performance metrics such as **throughput** and **latency**.
+## Run a read test
+
+Run a read benchmark on your Cassandra database using `cassandra-stress`. This simulates multiple clients reading from the cluster at the same time and records performance metrics such as throughput and latency.
 
 ```console
 ~/cassandra/tools/bin/cassandra-stress read n=10000 -rate threads=50
 ```
-You should see output similar to the following:
+
+The output is similar to:
+
 ```output
 ******************** Stress Settings ********************
 Command:
@@ -322,21 +325,24 @@ Total operation time      : 00:00:02
 END
 ```
 
-## Benchmark Results Table Explained:
+## Understand benchmark results
+
+The metrics below explain what each value in the `cassandra-stress` output represents:
+
+- Op rate (operations per second): the number of read operations Cassandra successfully executed per second.  
+- Partition rate: the number of partitions read per second. Since this is a read test, the partition rate equals the op rate.  
+- Row rate: the number of rows read per second. Again, for this test it equals the op rate.  
+- Latency mean: the average time taken for each read request to complete.  
+- Latency median: the 50th percentile latency - half of the operations completed faster than this time.  
+- Latency max: the slowest single read request during the test.  
+- Total partitions: the total number of partitions read during the test.  
+- Total errors: the number of failed read operations.  
+- GC metrics (Garbage Collection): shows whether JVM garbage collection paused Cassandra during the test.  
+- Total operation time: the total wall-clock time taken to run the benchmark.  
 
-- **Op rate (operations per second):** The number of read operations Cassandra successfully executed per second.  
-- **Partition rate:** Number of partitions read per second. Since this is a read test, the partition rate equals the op rate.  
-- **Row rate:** Number of rows read per second. Again, for this test it equals the op rate.  
-- **Latency mean:** The average time taken for each read request to complete.  
-- **Latency median:** The 50th percentile latency — half of the operations completed faster than this time.  
-- **Latency max:** The slowest single read request during the test.  
-- **Total partitions:** The total number of partitions read during the test.  
-- **Total errors:** Number of failed read operations.  
-- **GC metrics (Garbage Collection):** Shows whether JVM garbage collection paused Cassandra during the test.  
-- **Total operation time:** The total wall-clock time taken to run the benchmark.  
+## Benchmark summary for Arm64
 
-### Benchmark summary on Arm64
-Results from the earlier run on the `c4a-standard-4` (4 vCPU, 16 GB memory) Arm64 VM in GCP (SuSE shown, Ubuntu results were very similar):
+Results from the run on the `c4a-standard-4` (4 vCPU, 16 GB memory) Arm64 VM in GCP (SUSE shown; Ubuntu results were very similar):
 
 | Metric                     | Write Test             | Read Test              |
 |----------------------------|----------------------|----------------------|
@@ -356,12 +362,12 @@ Results from the earlier run on the `c4a-standard-4` (4 vCPU, 16 GB memory) Arm6
 | Total GC Time               | 0.0 s                | 0.0 s                |
 | Total Operation Time        | 0:00:00              | 0:00:02              |
 
-### Cassandra performance benchmarking notes
-When examining the benchmark results, you will notice that on the Google Axion C4A Arm-based instances:
+## What you've accomplished and what's next
+
+You've successfully deployed Apache Cassandra 5.0.5 on a Google Axion C4A Arm-based virtual machine, validated its functionality, and measured its performance using cassandra-stress. The benchmark results on Google Axion C4A Arm-based instances demonstrate strong performance characteristics. 
+
+Write operations achieved high throughput of 10,690 op/s, while read operations reached 4,962 op/s on the `c4a-standard-4` Arm64 VM. Write latency was notably low with a mean of 3.7 ms compared to reads at 6.3 ms, indicating fast write processing on this Arm64 VM. The 95th and 99th percentile latencies show consistent performance, with writes significantly faster than reads. Zero errors or GC overhead confirm stable and reliable benchmarking results. 
 
-- The write operations achieved a high throughput of **10,690 op/s**, while read operations reached **4,962 op/s** on the `c4a-standard-4` Arm64 VM.  
-- Latency for writes was very low (mean: **3.7 ms**) compared to reads (mean: **6.3 ms**), indicating fast write processing on this Arm64 VM.  
-- The 95th and 99th percentile latencies show consistent performance, with writes significantly faster than reads.  
-- There were no errors or GC overhead, confirming stable and reliable benchmarking results.  
+The Arm64 VM provides efficient and predictable performance, making it suitable for high-throughput Cassandra workloads. The low write latencies and high operation rates demonstrate that Arm-based infrastructure can effectively handle database operations that require both speed and consistency. These results provide a solid baseline for evaluating Cassandra performance on Arm64 architecture and can guide decisions about instance sizing and configuration for production deployments.
 
-Overall, the Arm64 VM provides efficient and predictable performance, making it suitable for high-throughput Cassandra workloads.
+To continue building on this foundation, you can explore advanced Cassandra configurations such as multi-node cluster deployments, replication strategies for high availability, or performance tuning for specific workload patterns. You might also investigate integrating Cassandra with application frameworks or comparing performance across different Arm-based instance types to optimize for your use case.