What is a Workspace

The need for shared data grows exponentially as companies need to leverage up-to-date data across their organization for informed decision-making and to introduce new products and services.

Traditionally, data sharing was achieved by copying data across various storage solutions and applications, resulting in a complex web of data and applications across disparate data solos. The drawbacks of such solutions were increased cost, complexity and latency, resulting in critical applications operating on stale data.

Workspaces enable customers to run multiple workloads on isolated compute deployments while providing ultra low-latency access to shared data. This ensures applications are always operating on the latest data.

A workspace is an independent deployment of compute resources which can be used to run a workload. It allows on-the-fly scaling of compute independently from storage. Each workspace can attach and detach databases as needed. A database may be attached to many workspaces simultaneously, allowing multiple workloads to operate on shared data. This allows data to scale across workloads without the complexity and cost of managing data across different data silos.

Workspaces are available in all editions of SingleStore Helios.

Benefits of Using Workspaces

  • Allows granular scalability and isolation of compute resources.

  • Eliminates the cost of moving and maintaining data between multiple workloads.

  • Removes consistency challenges by eliminating data silos.

  • Provides real-time access to data without the added latency of manual data movement.

Unique Workspace Design

SingleStore is the only real-time hybrid transaction/analytics processing (HTAP) database designed on a modern distributed SQL architecture. This means that compute can be scaled out using the native clustered architecture, rather than simply scaling up using larger machines. Workspaces further enhance this distributed architecture by freeing databases from the confines of a single cluster, delivering the true value of separate compute and storage.

Some enterprise data warehouses offer a similar separation of compute and storage, but since they are designed primarily for analytic workloads, they sacrifice latency to enable this flexibility. This is because writes are forced to go to object storage, which introduces latency and causes queries to return stale data if changes have not been propagated completely across the storage stack.

SingleStore is designed to power modern applications, where real-time access to data and low latency query responses are just as important as scalability and concurrency. To meet this need, SingleStore workspaces are designed to provide low latency data access to databases across every workspace deployed within a group (a logical tool for the organization of workspaces). Each separate application running on an independent workspace can be scaled up or down, while still ensuring fast access to fresh data.

Workload Examples

  • Scale ingest and compute workloads independently.

  • Deploy a workspace for batch reporting or one-time jobs on existing data and terminate it when the work is complete.

  • Run multiple customer facing and internal real-time applications simultaneously on shared data.

Examples of Sharing Databases Across Workloads

In the examples below, S-XX indicates the workspace size, that is, the number of vCPUs and amount of memory available for a workload.

1. Isolation and Scalability

You can have two workspaces, each having a different purpose access the same database in total isolation from each other.

  • Load data into the database from "Ingest Workspace" as R/W (read and write).

  • Serve the customer application from "App Workspace" as R/O (read only).

  • Scale the workspaces up or down independent of each other

    • Grow and shrink Ingest Workspace as needed. In this example, the size is increased from S-4 to S-16 when there is an increase in data ingestion volume. You can shrink it back to S-4 as soon as the volume reduces.

    • Grow App Workspace as user count increases. The size can be increased only when the number of users in this workspace goes up significantly to warrant it.

2. Customer App plus Batch Reporting

You can quickly spin up additional workspaces of any size attached to the same database whenever there is a requirement.

  • Serve the customer application from "App Workspace" (R/W).

  • Create a temporary "Reporting Workspace" to generate weekly reports.

    • Attach the database for reporting (R/O).

    • Run the reporting workload.

    • Terminate the reporting workspace when done.

3. Multiple Workloads, Shared Data

You can have internal and external facing applications using workspaces of different sizes to access the same database without affecting each others performance.

  • Serve the customer facing application (R/W).

  • Run the internal health dashboard for customers app (R/O).

  • Workloads run on isolated compute

    • The health dashboard app workload does not affect the customer app workspace.

Workspace Architecture

The workspaces are built using the native data replication engine built into SingleStore’s database. The isolated pools of compute resources are clustered on top of cloud hardware. These compute pools have dedicated memory and persistent disk cache to deliver immediate query responsiveness, while operating on top of bulk scale-out object storage.

Combined with SingleStore’s query code generation and tiered Universal Storage architecture, this allows workspaces to deliver extremely low latency query response, highly concurrent access and fast parallel streaming ingest while automating the movement of data across workloads.

Last modified: February 23, 2024

Was this article helpful?