Sign inTry Free

Warning

SingleStore 9.0 gives you the opportunity to preview, evaluate, and provide feedback on new and upcoming features prior to their general availability. In the interim, SingleStore 8.9 is recommended for production workloads, which can later be upgraded to SingleStore 9.0.

Cluster Components

On this page

Key Components

The following components are fundamental to a SingleStore cluster. They are also key terms that are used throughout the documentation.

Cluster

A cluster encompasses all of the nodes that are included in a complete SingleStore DB installation.

A cluster contains aggregator nodes and leaf nodes.

Node

A node is a server that has an installation of a SingleStore DB instance.

See Node Requirements for SingleStore Commands to learn about the commands supported by different types of nodes.

Leaf

A leaf is a node that stores a subset of a cluster’s data. It functions as a storage and compute node. To optimize performance, SingleStore automatically distributes data across leaf nodes into partitions. Each leaf contains several partitions. A cluster typically contains many leaves. Each leaf is in one of the Cluster Management Commands.

Partition

A partition contains a subset (a shard) of a database’s data. Each partition holds a vertical slice of data, distributed as per a hashing algorithm on the primary key or randomly for keyless sharded databases. A leaf node contains multiple partitions. When you run CREATE DATABASE, SingleStore splits the database into partitions, which are distributed evenly among available leaf nodes. With CREATE DATABASE, you can specify the number of partitions with the PARTITIONS=X option.

If you don’t specify the number of partitions explicitly, the default is used (the number of leaf nodes times the value of the default_partitions_per_leaf engine variable.

Tables

    SingleStore stores data in tables, which can be of one of the following types:

  • Universal Storage - (Default) Supports large-scale Online Transaction Processing (OLTP) and Hybrid Transactional and Analytical Processing (HTAP) workloads at a lower total cost of ownership (TCO). Universal Storage is a continuing evolution of the columnstore and supports transactional workloads that would have traditionally used the rowstore. SingleStore recommends using the Universal Storage tables for all kinds of workloads.

  • Rowstore - In-memory rowstore tables for high-performance OLTP workloads.

    The tables can have the following properties:

  • Sharded or Reference - A sharded table’s data is distributed across partitions. By contrast, a reference table’s data is replicated, in full, to all nodes in a cluster.

  • Persisted or Temporary - Defines whether the data stored in a table is persisted or stored temporarily for the duration of a client session. Temporary tables can further be classified into regular temporary tables and global temporary tables.

Aggregator

An aggregator is a node that routes queries to the leaves, aggregates the intermediate results, and sends the results back to the client. There are two types of aggregators: master and child.

A master aggregator is a specialized aggregator responsible for cluster monitoring and failover. It orchestrates basic cluster operations and all DDL operations. Refer AGGREGATOR SET AS MASTER for more details.

A cluster contains exactly one master aggregator. A cluster may also contain zero or more child aggregators (depending on query volume).

Aggregator to Leaf Ratio

The minimal setup for a SingleStore cluster is just one aggregator (the master aggregator) and one leaf. You can add more aggregators, which will read metadata from the master aggregator, and can run DML commands on the leaves.

The number of deployed aggregator and leaf nodes determines the storage size and performance of a cluster. Typical deployments have a 5:1 ratio of leaf:aggregator nodes. In a well-designed cluster:

  • Applications that require higher connection capabilities from application servers have a higher aggregator-to-leaf node ratio.

  • Applications with larger storage requirements have a higher leaf-to-aggregator node ratio.

Last modified: June 22, 2022

Was this article helpful?

On this page

Was this article helpful?

Verification instructions

Note: You must install cosign to verify the authenticity of the SingleStore file.

Use the following steps to verify the authenticity of singlestoredb-server, singlestoredb-toolbox, singlestoredb-studio, and singlestore-client SingleStore files that have been downloaded.

You may perform the following steps on any computer that can run cosign, such as the main deployment host of the cluster.

  1. (Optional) Run the following command to view the associated signature files.

    curl undefined

  2. Download the signature file from the SingleStore release server.

    • Option 1: Click the Download Signature button next to the SingleStore file.

    • Option 2: Copy and paste the following URL into the address bar of your browser and save the signature file.

    • Option 3: Run the following command to download the signature file.

      curl -O undefined

  3. After the signature file has been downloaded, run the following command to verify the authenticity of the SingleStore file.

    echo -n undefined |
        cosign verify-blob --certificate-oidc-issuer https://oidc.eks.us-east-1.amazonaws.com/id/CCDCDBA1379A5596AB5B2E46DCA385BC \
          --certificate-identity https://kubernetes.io/namespaces/freya-production/serviceaccounts/job-worker \
          --bundle undefined \
          --new-bundle-format -
    Verified OK