Workspace Scaling

Overview

When deploying databases in the cloud, users expect to be able to scale resources up or down depending on their workload. In reality, many databases make it easy to scale reads but provide no way to dynamically scale writes. For developers building dynamic applications, this provides a significant challenge.

SingleStoreDB Cloud has a unique architecture which offers the flexibility to scale resources dynamically, for both read and write workloads. This is enabled because SingleStoreDB is built on a clustered architecture which is distributed across compute resources. As workloads grow, resources can be added or removed in a dynamic and fully online manner to allow applications and workloads to scale.

Compute workspaces can be scaled up or down to accommodate changing workloads. The size of a workspace for example, S-32, determines the overall number of compute resources (vCPU cores and memory) available for a workload.

SingleStoreDB is a distributed SQL database, so scaling operations can be performed online by adding or removing resources without impacting the overall deployment. Hence the connectivity to a workspace is not affected during the scaling operation.

How Scaling Works

A SingleStoreDBcompute “workspace” is made up of individual nodes, which allow an even distribution of jobs across the underlying cloud resources. From a user's perspective, all that is required is to select a size (for example, S-64) and SingleStoreDB automatically provisions all the necessary resources.

When a user triggers a scale up or scale down operation SingleStoreDB automatically determines the number of compute resources required and adjusts the size of the workspace on the fly.

When scaling up, SingleStoreDB adds compute resources to the existing workspace, increasing the performance and capacity of the compute deployment.

When scaling down, SingleStoreDB removes a portion of the resources available for the workspace, without impacting the availability of the workspace itself.

Some databases allow online scaling within a single machine type, but workloads are limited by the maximum size of a host. Leveraging a distributed SQL architecture, SingleStoreDB can scale across hosts to reach extreme sizes for even the most intense enterprise workloads.

Scaling - Cloud Portal UI

Scaling up or down can be triggered through the UI or Management API. When scaling a workspace through the UI a user can simply select a workspace, open the workspace options menu (⋮), and select Resize Workspace.

This will open a menu where the user can choose a target workspace size.

Scaling - Management API

Scaling up or down through the management API can be done by using WorkspaceUpdate size. An overview of the management API can be found here: Overview.

High Availability

Critical workloads need to stay online, even when scaling the underlying resources. Rather than forcing users to take downtime when scaling, SingleStoreDB leverages its unique distributed SQL storage engine to handle resource provisioning without a major impact on read or write workloads. This is possible because of a high availability framework called “Load-Balanced Partition Placement.” In this architecture data is replicated within the distributed cluster, and applications maintain the ability to read and write even when the underlying resources are being added or removed:

Scaling Impact on Performance

Scaling operations trigger the online addition or removal of compute resources, as well as a redistribution of data to ensure even performance across the compute workspace. When the scale operation is running there may be a temporary reduction in performance due to resources being dynamically added or removed.

For large deployments with heavy active workloads the time required to complete the scaling operation may increase as a larger volume of active data needs to be redistributed within the workspace. The resize operation and data rebalancing will continue in the background while the workload is running, so no extra steps need to be taken to ensure the job completes.

Progressive Scaling

A further enhancement to the way SingleStoreDB scales workloads is progressive scaling. This optimization further segments underlying resources, to allow smoother incremental scale-up and scale-down of compute.

The net effect is faster scaling of resources, and a smaller impact to workloads when scaling up read and write capacity. This makes it possible to scale up or down significantly without worrying about bringing down existing running applications.

Billing

Workspaces consume compute credits while they are running. When a workspace is scaled up or down the number of credits consumed will change depending on the size of the workspace. This is reflected in the Resize Workspace > Review Changes menu. Both the current credit consumption and the new consumption for the target workspace size will be shown.

Workspace scaling does not affect the storage costs, as storage is charged based on the average number of monthly GB stored, which does not change when workspaces are scaled up or down.