What type of storage does SingleStore have?
SingleStore offers several storage modes to enable best-in-class performance for a wide variety of workloads and use cases. Many storage-related optimizations take place in the SingleStore engine and are not exposed to or configurable to the end-user; the essential user-configurable storage type options are as follows:
Rowstore vs. Columnstore:
These terms refer to how the data in database tables are stored sequentially. Rowstores are the original orientation used in traditional legacy RDBMSes; in a rowstore table, successive data values in a row are stored sequentially on the storage medium (i.e., in successive address locations). Columnstore orientation is a relatively more recent invention, in which the sequence of stored data is instead by consecutive data values in each column. Tables in Singlestore are created as columnstore tables by default but can be created as rowstores using the CREATE ROWSTORE TABLE syntax or by resetting the default table type. For more discussion of the relative advantages of rowstore and columnstore data, you can check here.
In-memory vs. on-disk:
Data in SingleStore is stored both in memory to optimize performance and on disk to ensure durability and reduce operating costs. Memory and disk storage are leveraged differently in the rowstore and columnstore tables. Rowstore tables persist the entirety of their data in memory, which allows them to optimize for fast and highly concurrent transactional workloads that require millisecond read and write performance. In addition, rowstore tables simultaneously persist the data to disk to remain durable in a hardware outage. Columnstore tables ingest data through a dedicated in-memory rowstore segment to optimize ingest performance; the size of this ingest buffer can be configured depending on how much recently-ingested data needs to be kept in memory for fast access. Columnstore data outside of the ingest buffer is stored in columnar blobs on disk in a highly compressed format, allowing fast reads while minimizing the amount of hardware required for the terabyte-scale datasets typical of analytic use cases. Due to Linux buffer paging, frequently-queried columnstore data will also remain in memory so that “hotter” columnstore data will naturally benefit from fast access times.