Skip to content

Positioning of MatrixOne

Among the large and complex data technology stack and various database products, MatrixOne is positioned as a SQL relational database focused on one-stop convergence and flexible scalability. MatrixOne was designed to provide a database product with a user experience as simple as MySQL that can handle a variety of business loads and data types, including OLTP and OLAP, while being aware of user load and data volume changesAutomating rapid elastic scaling to simplify the user's current complex multi-database product+ETL legacy data architecture.

The database product closest to MatrixOne among the industry's existing database offerings is SingleStore, both of which use a unified storage model that supports the convergence of OLTP, OLAP, and a host of other data loads and data types, while also both having cloud native and flexible scalability as their core architectural capabilities.

mo_vs_singlestore

  • Architecturally, MatrixOne is a fully cloud-native and containerized database. MatrixOne draws on Snowflake's computational separation design for cloud-native data warehouses, completely handing over storage to shared storage on the cloud, while fully building the compute layer into a stateless container. At the same time, to accommodate the processing of fast write requests by OLTP-type loads, MatrixOne adds the concepts of TN and LogService to support high-frequency writes with block storage, ensures high availability of write log WALs with Raft triple copy consistency guarantee, and asynchronously drops WALs into shared storage. Unlike SingleStore, which extends from the Share-nothing architecture to cloud-native memory separation, it only puts cold data in shared storage (see SingleStore architecture paper) and still requires data fragmentation and rebalancing. MatrixOne, on the other hand, is consistent with Snowflake and is entirely based on shared storage without any data fragmentation.

  • In terms of load types, MatrixOne uses HTAP as its basic core and gradually expands into a variety of load types such as stream computing, timing processing, machine learning, and search. On HTAP's technical route, MatrixOne differs from the TiDB-based dual storage and compute engine route in that MatrixOne implements HTAP directly on a single storage and compute engine, and the storage engine is also a disk drop-row-row-row-row-row-row-row-only architecture, which is also more consistent with SingleStore. Technical routes such as TiDB require internal dual-engine data synchronization, while TP and AP data need to be stored separately, while MatrixOne does not need to do this synchronization and multiple storage. Compared to SingleStore, which already has good support for a variety of business types other than HTAP for streaming computing, search, GIS, machine learning, etc., MatrixOne itself evolved late and is currently less well supported for other load types other than HTAP.

  • Experience-wise, MatrixOne has MySQL as its core compatibility goal, including full MySQL compatibility from transport protocols, SQL syntax, and basic functionality. MatrixOne only has its own unique syntax on capabilities that MySQL does not support, such as streaming writes, vector types, etc. Meanwhile MySQL has some advanced capabilities such as triggers, stored procedures, etc. MatrixOne is not yet supported due to low user usage. In general, MySQL-based applications can be migrated to MatrixOne very easily, while MySQL eco-related tools such as Navicat, DBeaver and other visual management and modeling tools, DataX, Kettle and other ETL tools, as well as Spark, Flink and other computing engines, can be used directly with MySQL-related connectors to interface with MatrixOne.