Google Cloud Platform Blog: Speed with Ease – NoSQL on the Google Cloud Platform

Google Cloud Platform Blog

Product updates, customer stories, and tips and tricks on Google Cloud Platform

Speed with Ease – NoSQL on the Google Cloud Platform

Wednesday, October 21, 2015

Today’s guest bloggers are Lynn Langit – Independent Cloud and Big Data Architect named the Google Cloud Developer Expert for the past three years and recognized as an AWS Community Hero, Microsoft MVP (SQL Server), MongoDB Master and ACM Distinguished speaker – and David Haley, startup engineer and former Google Cloud team member who was the first engineer on the Google Cloud Platform Americas sales team. Validating 4 Million TPS using AerospikeDB with only 20 GCE nodesDecember 2014 benchmarkAerospikeleveraging SSDsfour times the performance at half the price was measuredkey-value store New Benchmark Validated – TL; DR – 6 Simple Steps to Speed About Aerospike Scaling:

Aerospike handles the equivalent of sharding automatically.

There’s no downtime. You can add new capacity (data volume and throughput) dynamically. Simply add additional nodes and Aerospike will automatically rebalance the data and traffic.

You set the replication factor to 2 or more and configure Aerospike to operate with synchronous replication for immediate consistency and durability.

If a server goes down, Aerospike handles failover transparently; the Aerospike client makes sure that your application can read or write replicated data automatically.

You can run purely in RAM, or take advantage of Flash/SSDs for storage. Using Flash/SSDs results in a slight penalty on latency (~0.1ms longer on average), but allows you to scale with significantly smaller clusters and at a fraction of the cost.

Benchmark Testing on GCE – TL; DR – look ma’ it’s fast Setup to Test Aerospike on Compute Engine Step OneSETUP Compute Engine Environmenthttps://cloud.google.com/https://cloud.google.com/sdk/

NoteTo replicate the 4 million TPS benchmark, you’ll need to enable project billing and then request an increase in the default quota limits for a GCP project, as you’ll need to increase the default CPUs/project limit from 24 to 160.
To do this, from within your new project in the GCP console > Compute > Compute Engine > Quotas and then click on the "Change Request" link at the top of the page. Fill out the form and click send. It generally takes around 24 hours for this type of request to be processed.

Step Two

SETUP Compute Engine instances for the Aerospike server clusterAerospike Java client

LOGIN to your Google Cloud accountSETUP variable values as for your test.your-project-name
CREATE 20 GCE instances Step Three UPDATE the Aerospike config files

Step Four

SETUP Compute Engine instances for the Aerospike client VMs. To perform the test at the scale for benchmark validation, I created 20 client GCE VMs. For the benchmark work, we chose machine types of n1-highcpu-8 because the benchmark tool workload uses 256 threads in order to appropriately saturate the server nodes. I used the same custom image with Aerospike pre-installed to create the clients as I used when creating Aerospike server nodes and identified these nodes via the tag value “benchmark-client.”

Step Five

CREATE AEROSPIKE CLUSTER by booting the servers: Start the asd daemon on each server using the aerospike.config file. You run lines 64-74 to complete this task, also shown below.

Step Six

Start the AMC (GUI) Console: Although the Aerospike benchmark tool does generate text-based (log) output, I find that "seeing" the power via the Aerospike Management Console (GUI) is a fun part of testing. A portion of a sample AMC console is shown above.

To connect to the AMC console, you’ll need to find the public IP of "as-server-1" and then open a browser using http://(public_IP_of_server-1):8081. Next you’ll enter the private (internal) IP in the dialog box that opens on top of the AMC as follows: http://(internal_IP_of_server-1):3000.

Run Tests using the Benchmark Tools

The Java client for Aerospike includes the Aerospike benchmark testing tools. Because we installed the Java client on our base image, all client instances include the benchmark tools – we simply need to “turn on the tool” to perform a load test. There are a number of parameters that you can use with the benchmark tool (detailed at the end of this section). To perform the test, I set the load parameters to 1 Million Keys and 256 client threads. Run the test. First l generated the load for the insert benchmark, and then I ran the test with a different load type.

Shown below is the first result in the AMC – it’s actually considerably MORE than previous 1 Million TPS – it’s 4 Million! Of note is that only 50 GB (of the total available 350 GB) of RAM available to the cluster is being used for this workload. This first test uses 100% reads for the workload.

For this next test, I ran the benchmark tool with the configuration set to 100% WRITES. This test resulted in a 1 Million TPS as shown in the AMC console image below. Again, of interest, is that only 50 GB (of the total 350 GB) or RAM is being used to run this workload.

Benchmark Tool Script Details

The host in the “-h” option of the benchmark tool must be used to test against the Aerospike host node. Benchmark options used in the current tests were:

10 million keys (-k 10000000)

50 byte string values for each key (-o S: 50) – 150 byte into 3 bins + key -> 200 byte objects

3 bins or columns each of size 50 and insert key size of 20 bytes (-b 3 -l 20)

Two different loads:

100% write (-w I)
100% read (-w RU, 100)

Before every test run, data was populated using the insert workload option (-w I)

For each client instance, 256 threads give the maximum throughput in the in-memory database case (-z 256).

For more about benchmark flags, use benchmarks -help

Clean Up

When you’ve completed your testing, you’ll want to stop the test. You may also want to stop the Aerospike servers, delete disks and shutdown all VM instances. Run the referenced script from line 130 to the end (line 165) to stop the benchmark tests, stop all of the servers, delete all disks and shutdown all instances.

Conclusions and Next Steps

I found the combination of Aerospike and GCP to be a winner for these reasons:

Powerful, scalable NoSQL Database – I was able to set up and test with ease

Quick setup and low cost to test – for this configuration the cost looks to be around 4k/month – this is for up to 4 million reads per SECOND, many customers won’t need this much power, so running fewer servers would reduce costs

Flexibility of cloud platform – scaling up or down is trivial given the sharding of Aerospike and the speed of working with Compute Engine VMs

speed with (n) number of servers, to further simplify management and thereby reduce overall cost?" Also, I could alter the test parameters to match whatever type(s) of real-world workloads I need. For example, I may test a common 80% read, 20% write mixed workload as client requests dictate in the future.

Note: On Compute Engine Machine Types. I chose the n1-standard-8 series of instances, as these are “middle-of-the-road” instance types and provide a good instance-to-value ratio. Of course, Compute Engine offers a variety of instance sizes and types – a grid summarizing choices is shown below.