General
What are license units and how do they apply to my cluster?
Previous versions of SingleStoreDB 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 SingleStore Customer 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: SingleStoreDB 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 | SingleStoreDB 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, SingleStoreDB will consider you to have two potential license units if you used that machine as a host. To artificially constrain your capacity, deploy SingleStoreDB onto a virtual machine instead with fewer resources to lower your license unit count per host (which would be considered the virtual machine).
What is the relationship between SingleStoreDB and MySQL?
SingleStoreDB is a standalone distributed database that is compatible with MySQL client software.
SingleStoreDB is not a storage engine or other component of MySQL, nor is MySQL a component of SingleStoreDB, and the SingleStoreDB and MySQL servers do not share any code. The SingleStoreDB 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 SingleStoreDB server. SingleStoreDB 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, SingleStoreDB 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 SingleStoreDB server version. The SingleStoreDB 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 SingleStoreDB 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 SingleStoreDB.
Is SingleStoreDB vulnerable to MySQL server security issues?
No. The SingleStoreDB and MySQL servers are separate database engines which do not share any code, so security issues in the MySQL server are not applicable to SingleStoreDB.
SingleStoreDB 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 SingleStoreDB is not susceptible to these MySQL vulnerabilities.
Is SingleStoreDB a row-based or column-based store?
SingleStoreDB 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
andDELETE
queriesRequires more expensive query compilation (as compared to the row store)
How does SingleStoreDB’s in-memory lock-free storage engine work?
SingleStoreDB’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 SingleStoreDB are never blocked, but updates to the same row can conflict with logical locks.
What is the advantage of SingleStoreDB 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, SingleStoreDB has four distinguishing memory-optimized features that enable it to perform significantly better than disk-based storage engines running in memory:
SingleStoreDB is a distributed scale-out system. SingleStoreDB 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. SingleStoreDB 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, SingleStoreDB compiles SQL down to native code for maximum performance.
What is the advantage of SingleStoreDB over other distributed databases?
Full SQL. SingleStoreDB supports full SQL and transactional semantics.
Storage pyramid. SingleStoreDB combines row and column store engines tuned for memory and flash storage.
Scales on commodity hardware. SingleStoreDB does not require exotic hardware and can run on-premises or in the Cloud.
Enterprise ready. SingleStoreDB supports a large number of enterprise security and manageability features.
What is SingleStoreDB not for?
SingleStoreDB 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 SingleStoreDB is not designed to run. Some of these are listed below:
Object store.SingleStoreDB 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. SingleStoreDB 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.SingleStoreDB 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 SingleStoreDB for development is to use the SingleStoreDB Dev Image.
In-process database.SingleStoreDB is not run as a library or in-process with an application. SingleStoreDB is a distributed database which runs in separate processes from the application, and applications connect to SingleStoreDB via a client driver.