General

What are license units and how do they apply to my cluster?

Previous versions of SingleStore used available RAM for pricing and to define the boundary between free and enterprise licenses. If you already have one of these RAM-based licenses, you can continue to use it when upgrading to newer versions of MemSQL; however, MemSQL 6.7.13 and later now support licenses based on the concept of units. All new licenses generated in the Cloud Portal will be unit-based licenses.

A unit is a combination of compute (8 vCPU or less) and RAM (32 GB or less) and only applies to hosts that run leaf nodes in a cluster. Note: SingleStore counts the number of virtual cores available to a processor, regardless of whether hyper-threading is enabled or not.

The size of the host (physical or virtual) determines how many license units will be counted when you add leaf nodes to that host to your cluster. The total license units for a host are calculated by taking the total RAM of the host divided by 32, or the total number of vCPUs divided by 8, and rounding up. Whichever is the greater value (RAM or vCPU) is the number of potential license units on that host. Because this only applies to leaf nodes in your cluster, aggregator nodes are not part of the license unit calculation and can be deployed on any quantity or size of hosts that meet the minimum hardware requirements for installation.

To help understand how license units are calculated, the following table provides examples of how many license units would be counted for various AWS EC2 instance types:

Host Size

RAM

vCPU

SingleStore License Units

m5.2xlarge

32

8

1

c5.2xlarge

16

8

1

i3.2xlarge

61

8

2

r5.2xlarge

64

8

2

m5.4xlarge

64

16

2

m4.10xlarge

160

40

5

You can artificially constrain or limit the number of license units to a subset of the resources available by lowering the resources available to a host that you are deploying a leaf node onto. For example, if you have a physical machine with 16 vCPU and 48 GB of RAM, SingleStore will consider you to have two potential license units if you used that machine as a host. To artificially constrain your capacity, deploy SingleStore onto a virtual machine instead with fewer resources to lower your license unit count per host (which would be considered the virtual machine).

Refer to Determining capacity and usage for your license for more information.

What is the relationship between SingleStore and MySQL?

SingleStore is a standalone distributed database that is compatible with MySQL client software.

SingleStore is not a storage engine or other component of MySQL, nor is MySQL a component of SingleStore, and the SingleStore and MySQL servers do not share any code. The SingleStore server includes its own storage engine and SQL-based execution engine built around scalable distributed execution, lock-free data structures, and machine code generation.

Users use MySQL client software to connect to the SingleStore server. SingleStore uses the same wire protocol as MySQL and supports similar SQL syntax as MySQL for compatibility with MySQL client software.

Why do I see the MemSQL version as 5.5.8, even though that’s not the version of MemSQL I installed?

For compatibility with MySQL client software, SingleStore reports the version engine variable as 5.5.8. Client drivers look for this version to determine how to interact with the server.

This is not the SingleStore server version. The SingleStore server version can be found in the memsql_version engine variable, which can be queried like SELECT @@memsql_version.

As a result, certain MySQL clients may display the server version as 5.5.8, even though this is not the SingleStore version. For example, the mysql command line client may display

Server version: 5.5.8 MemSQL source distribution (compatible; MySQL Enterprise & MySQL Commercial)

when you connect to SingleStore.

Is SingleStore vulnerable to MySQL server security issues?

No. The SingleStore and MySQL servers are separate database engines which do not share any code, so security issues in the MySQL server are not applicable to SingleStore.

SingleStore implements the MySQL wire protocol in order to provide compatibility with MySQL client software. A part of this compatibility involves reporting a MySQL version number as described above. As a result of this, numerous third-party security scanners that use the reported version number as a vulnerability marker report false positives, as they’re looking at a version number, not at the actual presence of a vulnerability. Our engineering team as well as a third-party security analysis have confirmed that SingleStore is not susceptible to these MySQL vulnerabilities.

Is SingleStore a row-based or column-based store?

SingleStore provides both in-memory row-based and on-disk column-based stores.

The in-memory row store:

  • Works best for mixed transactional and analytical workloads

  • Provides low latency and highly concurrent reads and writes of individual rows as well as sophisticated analytical SQL queries

  • Supports PRIMARY and UNIQUE keys

  • Supports geospatial indexes

  • Has longer recovery times (as the entire table needs to be loaded into memory)

The on-disk column store:

  • Works best for analytical workloads

  • Allows tables larger than the amount of available RAM in the cluster

  • Uses compression (which lowers disk usage and accelerates replication)

  • Provides fast and efficient scans of large datasets

  • Provides sorted columnstore indexes

  • Is optimized for batch UPDATE and DELETE queries

  • Requires more expensive query compilation (as compared to the row store)

How does SingleStore’s in-memory lock-free storage engine work?

SingleStore’s storage engine uses multi-version concurrency control with lock-free skip lists and lock-free hash tables which allow highly concurrent reads and writes at very high throughput. Reads in SingleStore are never blocked, but updates to the same row can conflict with logical locks.

What is the advantage of SingleStore over traditional databases like Oracle, SQL Server or MySQL with data in a ramdisk or large buffer pools?

Two common techniques for leveraging large amounts of memory in traditional databases are storing data files on a ramdisk or running a disk-based storage engine with a large buffer pool. For example, MySQL performs much better with InnoDB configured to use a large buffer pool.

While running an existing storage engine like InnoDB in memory can alleviate some of the bottlenecks involved with disk, SingleStore has four distinguishing memory-optimized features that enable it to perform significantly better than disk-based storage engines running in memory:

  • SingleStore is a distributed scale-out system. SingleStore scales to thousands of machines on commodity hardware.

  • No buffer pool. Traditional databases manage a global buffer pool since they assume that the dataset can’t fit into memory. The buffer pool is a resource shared across all databases and all tables, which creates significant contention.

  • Lock-free data structures. SingleStore uses memory-optimized, lock-free skip lists and hash tables as its indexes. Unlike B+ Trees, these data structures are designed from the ground up to be fast in memory.

  • Code generation. Lock-free data structures are so fast that dynamic SQL interpretation quickly becomes the limiting factor for query execution. With code generation, SingleStore compiles SQL down to native code for maximum performance.

What is the advantage of SingleStore over other distributed databases?

  • Full SQL. SingleStore supports full SQL and transactional semantics.

  • Storage pyramid. SingleStore combines row and column store engines tuned for memory and flash storage.

  • Scales on commodity hardware. SingleStore does not require exotic hardware and can run on-premises or in the Cloud.

  • Enterprise ready. SingleStore supports a large number of enterprise security and manageability features.

What is SingleStore not for?

SingleStore excels at real-time and high throughput query use cases. It is a general purpose database for running both transactional and analytic workloads. However, there are use cases which SingleStore is not designed to run. Some of these are listed below:

  • Object store.SingleStore is not designed to be a blob store. It is designed for high value data that is structured or semi-structured and ready to query. SingleStore has open-source connectors for integrating with a variety of object stores, including Amazon S3 and Hadoop File System (HDFS).

    See Load Data for more information.

  • Running on low hardware.SingleStore is not designed to run on micro instances, mobile phones or other low-powered computers. It is designed to run on machines with at least 4 cores and 8GB of RAM. The easiest way to run SingleStore for development is to use the SingleStore Dev Image.

  • In-process database.SingleStore is not run as a library or in-process with an application. SingleStore is a distributed database which runs in separate processes from the application, and applications connect to SingleStore via a client driver.

Last modified: January 10, 2023

Was this article helpful?