从 0 到 100TB，MatrixOne 助您轻松应对

作者：邓楠 MO 产品总监

随着传感器和网络技术的大规模应用，海量 IoT 设备产生了巨量数据，传统数据库方案难以满足这些数据的存储和处理需求。MatrixOne 是一款强大的云原生超融合数据库，具备优秀的流式数据写入和加工能力，同时拥有强大的可扩展性，能适应任意规模的负载和数据量。

本次分享主要分为以下三个部分：

Part 1. MatrixOne 设计理念及技术架构介绍

Part 2. MatrixOne 内核 1.0 版本功能介绍

Part 3MatrixOne 适用场景和最佳实践

Part 1 MatrixOne 设计理念及技术架构介绍

MatrixOne 是一款全新的分布式云原生数据库，它完全依照云计算特点进行设计，紧密贴合当前云计算发展趋势。其主要特性包括线性扩展能力以及存算分离，这两点正是数据库行业当前的发展趋势。

MatrixOne 内核能力突出，它是一款 HTAP（混合事务分析处理）数据库，同时具备流处理能力。简单来说，MatrixOne 可视为将 MySQL、ClickHouse 和 Flink 三种技术融合于一体的产品。它不仅具备分布式系统的扩展性，还能覆盖大部分事务处理和分析处理场景。

MatrixOne 是一个开源项目，欢迎大家浏览上图中列出的开源地址，以及用户手册，以便深入了解技术细节和使用说明。MatrixOne 在设计时，以国内最大的开发者社群 MySQL 8.0 为主要兼容对象，因此用户在迁移过程中可以轻松上手，几乎无需重新学习使用方式。

在当前大数据时代或 ABC 时代（人工智能、大数据、云计算），数据应用面临诸多挑战。其中一个关键问题是扩展性，数据的量和应用场景随着企业或应用的发展不断增长，需要保证在增长过程中数据应用能够具备相应的拓展能力。例如，一家公司从年收入零开始，逐渐发展到数十万、数百万、数千万甚至数亿级别。在这个过程中，数据量和应用需求也随之增长，这意味着数据架构必须随着时间推移和数据质量的变化不断调整。

以一家初创公司为例，初期可能只需一个简单的单体应用，使用 MySQL 主备即可。但随着公司成长，业务复杂度增加，数据量达到数十 GB 或百 GB 级别，单一数据库难以应对。此时，需要考虑分库、分表等方案，甚至引入更多组件如 Elasticsearch、ClickHouse、Hadoop、Spark 和 Flink 等。

这种情况下，MatrixOne 应运而生。之所以从零开始开发这款数据库，是因为现有的数据库产品虽然在单一能力上表现出色，但存在偏科现象。随着客户需求从简单到复杂、从小规模到大规模演变，需要多种组件来满足不同需求。

当前数据应用领域面临的一大挑战是满足不断变化的业务需求。针对这一挑战，MatrixOne 的核心理念就是超融合，即整合各类数据库的核心功能，满足用户最关心的需求。

超融合包括以下几个方面：

1. 分布式事务处理（OLTP）：支持高效的增删改查操作，满足流程交易型应用的需求。

2. 分析性应用（OLAP）：提供强大的数据分析能力，帮助企业挖掘数据价值。

3. 高速写入：支持大规模数据的快速写入，提升系统性能。

4. 实时性：满足实时流处理需求，实现实时报表和分析预测。

MatrixOne 通过完全重构底层数据引擎，基于先进架构设计出一款超融合的全功能数据库。这意味着企业只需使用一款数据库就能解决各类应用场景的问题，包括流程交易、实时报表和分析预测等。

MatrixOne 数据库分为社区版，企业版和公有云三个版本：

1. 社区版：开源免费，用户可以自由下载体验。

2. 企业版：在社区版基础上增加了一系列运维工具和周边组件，便于企业级用户管理和运维。

3. 公有云版本：完全托管的 Serverless 版本，即开即用，按使用量付费。

MatrixOne 的设计理念旨在帮助企业轻松应对不断变化的数据应用挑战，实现一站式解决方案。通过不同版本满足不同用户群体的需求，MatrixOne 成为了适应各类场景的优质数据库产品。

MatrixOne 的另外一个理念就是云原生与 Serverless，虽然在应用层开发者应用 K8s 等云原生技术已经相对普遍。但在数据层或数据库层，云原生化的程度仍有待提高。为实现真正的云原生数据应用，我们需将数据库完全容器化，使其具备自动化和弹性扩展的特点。为此，我们设计了 MatrixOne Cloud，将其 Serverless 化，使其与应用层一样具备完全自动扩展的能力。

MatrixOne Cloud 实现了以下几个设计理念：

1. 自动化资源供给：用户无需关心负载的变化，数据库会根据需求自动调整资源分配。

2. 弹性扩展：根据负载情况，自动进行扩容和缩容，实现资源的动态调整。

3. 按实际用量付费：用户只需为实际使用的资源付费。

4. 免运维：Serverless 架构使运维工作变得更加简单，消除了节点管理带来的复杂性。

5. 面向云设计：MatrixOne Cloud 与云上各类成熟组件（如 K8s、S3 等）无缝集成。

MatrixOne 是一款全新设计的数据库，致力于满足现代云原生环境的需求。它采用了几个关键技术架构，其中之一是存算与事务分离。这一架构将存储，计算和事务三大功能拆分开来，以实现更高的灵活性和性能。

在 MatrixOne 中，存储层采用了业界公认的廉价且易用的 S3 对象存储。这种存储方式具有高度可扩展性和可用性，已成为云原生数据库的首选。

计算层则采用无服务器架构（serverless），将计算节点（Compute Node）实现为云上的容器化 Pod。这些 Pod 内部几乎没有状态，仅包含一些缓存。这种设计使得 Pod 可以根据需求快速扩展，例如，瞬间创建 100 个甚至 1000 个 Pod。基于 Kubernetes 平台的自动化管理，可以高效地处理这些扩展需求。

通过这些技术架构，MatrixOne 能够充分利用云计算的优势，提供高性能、高可用的云原生数据库解决方案。

MatrixOne 数据库是一个 HTAP（混合事务处理和分析处理）数据库，实现了事务处理（TP）和分析处理（AP）的统一。这一架构的核心是将事务相关的处理单独拆分为 TN 结构。TN 负责写入相关的仲裁和调度处理，并将新写入数据存在内存中，日志则先写入共享日志组件（Log Service）。共享日志组件具有一定的状态，因此需要用到一个三副本的 Raft 组来保证高可用。TN 内存数据达到一定规模后会异步写入到 S3 存储中，并删除 Log Service 中的日志。这一设计使得 MatrixOne 能够实现 HTAP 的高效处理。

MatrixOne 还自主研发了存储引擎，存储引擎基于当前流行的 LSM Tree 技术。通过这一系列技术架构，MatrixOne 能为用户提供高性能、高可用的混合事务处理和分析处理能力，满足现代应用场景的需求。

此外，MatrixOne 还实现了存储层面的多级冷热分离，以适应云上架构特点。

首先，在架构设计上，S3 作为云上主存储的选择方案，在使用时需要处理其对于读写 I/O，尤其是小文件处理不友好的问题。为了使 S3 能够满足 HTAP 需求（特别是 TP 的需求），引入了多级冷热分离的存储策略。

在 CN（计算节点）中，采用了两层缓存机制。一层是内存缓存，另一层是 CN 节点内的本地磁盘，例如 SSD 硬盘。这种两级存储策略使得最热的数据存放在内存缓存中，次热的数据存放在本地磁盘，而相对冷的数据则会被存储在 S3 中。

Log service 共享日志模块，用于存储上面提到的事务日志，它需要用到相对读写更高效的块存储产品如 EBS。这种存储的 IO 能力介于缓存和 S3 之间，读写性能良好，但成本较高。因此，它更适合于处理相对小量的存储需求，并具有高达 5 个 9 的可用性。

多层冷热分离架构，可以实现对事务处理（TP）和分析处理（AP）请求的良好兼容性。

MatrixOne 的 HTAP 实现细节与行业中的主流做法也有差异。目前，行业中存在两种 HTAP 技术路线：一种是使用两个引擎，分别处理 TP 和 AP，将两个处理引擎合成为一个数据库；另一种是我们所采用的路线，即在一个引擎内通过区分不同链路来实现 HTAP。

两种方法核心差异在于写入和读取。写入方面，我们通过 TN（事务节点）处理所有相关仲裁。当写入请求到达 CN（代理层）后，相对比较大的数据块可直接写到 S3，而小数据则会写到 TN 的内存里。所有的写入 commit 信息都会记录到 TN 上。新写入的这些存在 TN 中的数据，我们叫 LogTail 会通过发布订阅形式推送到相关的计算节点 CN 的内存中。这意味着 CN 在服务读取请求时，能快速从 LogTail 找到最热的刚写入的数据即返回给用户。

通过这种方式，能够高效地服务于 TP 的小规模写入。对于 AP 相关的大规模查询，如果缓存或 LogTail 中没有所需数据，系统将直接从 S3 读取，由于 AP 的操作本身就会读较多数据，因此对 S3 的读取相对是比较友好的。总体而言，通过这种方式可以实现读写链路的区分，并在单一数据库内实现 HTAP 相关能力。

接下来介绍多租户和多负载自定义资源隔离相关的能力。MatrixOne 自带多租户能力，意味着可以在数据库中创建不同的租户，互相使用用不同的数据空间。不同的租户还绑定不同的计算资源组，也就是一个或者若干个 CN，这完全基于 Kubernetes 中容器之间固有的隔离性。我们可以通过 Proxy 服务中的标签形式来定义不同的 CN 组。这些组可以绑定在租户上，也可以进一步根据业务需求进行划分。

举个例子：在集群中存在两个租户。例如，租户 account1 拥有一个单独的资源 CN 组与之绑定。这个资源组可以自动管理扩展，可以指定最小 CN 个数和最多 CN 个数。同样，account2 也可以实现类似的配置。在 account1 内，可以进一步划分资源，将 CN 资源组进一步划分为写入资源组和查询资源组。这种灵活的资源划分和隔离策略为业务运行提供了便捷。

在云端，提供了自动扩缩容的能力，这是 Serverless 基础架构的基础。通过云原生相关的开源组件，如 KEDA，可以感知整个集群的负载。MatrixOne 具有一个独特之处，即会将集群的相关负载记录在 MatrixOne 内部。当集群或 CN（节点）的资源达到预设上限时，会触发扩容机制。这意味着，在达到特定阈值后，系统会自动调用 K8S 接口，增加 CN Set 的节点。由于这个过程实际上是调用 K8S 接口进行扩容，因此实现起来相当便捷。

接下来要介绍的一个技术要点是流引擎，也称为 streaming 能力。虽然目前流引擎仍处于实验阶段，尚未完全成熟，但在整个架构中，它发挥着至关重要的作用，也是真正实现 一站式 HTAP 处理的核心。

流计算主要解决两个问题：

第一，MatrixOne 的数据源可能多种多样，包括上游其他数据库或者 IoT 等设备产生的日志数据，都会需要实时入库。为了快速能接入不同数据源，流计算引擎负责处理前端写入数据的相关事宜。特别是，我们可以通过流引擎方便地接入诸如 Kafka 等消息队列，以及前端上游数据库相关组件。这些能力都被整合为一整套组件，从而将接入过程大大简化。

第二，数据从原始模型要经过一系列变换操作，最终转化为分析相关的表。在这个过程中，流引擎实现了数据转换相关功能，类似于数据仓库中的物化视图。通过对原始数据进行一定的变换，包括聚合和归一化操作，我们将数据转化为物化表。随后，通过查询这些物化表，实现了简化的数据处理链路。

这一创新之处在于，流引擎能够在数据库内部完成原始数据读取、处理和查询等操作，避免了将数据读取到外部进行处理后再写回数据库的繁琐过程。这也是我们一站式实现数据入库和使用的基础。

Part 2

MatrixOne 内核 1.0 版本功能介绍

MatrixOne 今年发布了 1.0 版本。整体实现了与 MySQL 8.0 高度一致的 SQL 语法，使得原有 MySQL 应用的迁移工作非常轻松便捷。其中包括 DDL（数据定义语言）和 DML（数据操作语言）等基本功能，涵盖了大部分常用数据类型。

在索引和约束方面，我们保持了与 MySQL 绝大部分能力的兼容，包括主键、唯一键、非空外键等。多租户相关能力是 MatrixOne 产品的一大亮点，通过数据库内部创建新租户，实现数据空间的隔离，便于 SaaS 应用处理多租户需求。同时，我们还支持租户间的数据发布订阅，允许在一定程度上实现数据互通，为用户提供更多便利。

在查询方面，1.0 版本已经涵盖了主流的基础查询和高级查询功能，满足基本的业务应用和数仓中的应用需求。其中包括窗口函数、CTE（公共表表达式）以及递归 CTE 等高级查询能力。此外，常用的聚合函数和系统函数也一应俱全。

目前，查询功能与 MySQL 的兼容度达到了约 70%-80%。虽然 MySQL 还具备一些更高级的功能，如触发器、存储过程等，但在实际应用中，这些功能的利用率相对较低。在后续版本中，我们将根据用户需求和行业趋势，逐步完善这些功能，以满足不同场景下的需求。

MatrixOne 支持事务处理，默认情况下使用悲观事务。悲观事务的处理方式与 MySQL 完全一致，主要包括使用 start 或 begin transaction 开始事务，commit 提交事务，以及 rollback 回滚事务等操作。

目前，默认使用悲观事务以及 RC（Read Committed）隔离级别。当然，用户可以根据需求切换到乐观事务以及 Snapshot isolation 等相关隔离级别。然而，在主流的行业应用中，悲观事务依然占据主导地位，主要是因为它便于应用程序的开发和维护。

在部署架构方面，提供两种版本：包括单机部署和分布式部署。

单机部署相当简单，只需将二进制文件、源码或 Docker 镜像安装到服务器上即可。对于分布式部署，需要依赖 Kubernetes（K8S）和 Amazon S3。企业版中已包含这些依赖项。

针对云上部署，各大主流云服务提供商都提供了现成的 Kubernetes 平台、对象存储等资源。可以利用这些资源，通过提供的 Operator 快速部署整个系统。

目前推荐的最小配置为 3 个 8c32g，作为分布式生产环境部署。更多关于部署架构的详细信息，请参考官方网站上的文档。

在开发和运维工具方面，MatrixOne 与 MySQL 高度兼容。针对使用 MySQL 开发应用程序，我们已经验证了主流框架和多种语言的兼容性，其中包括 Java、Python 和 Golang。尽管我们尚未完全适配其他语言，如 C# 或 Ruby on Rails，但简单试用后，预计其匹配度也相对较高。因为 MatrixOne 本质上与 MySQL 兼容性良好，所以在使用这些语言时，大多能无缝切换。

此外，常用的 ORM 框架如 MyBatis、MyBatis Plus、SQLAlchemy 和 GORM 等，均已深度适配 MatrixOne。针对数据库管理工具，MatrixOne 与 MySQL 高度通用，便于开发者使用熟悉的 Navicat，DBeaver 等工具。

另外，我们自研了备份工具，包括逻辑备份和物理备份，以满足不同需求。这些备份工具与 MySQL 原生备份有所区别，但使用起来同样便捷。例如，mo-dump 类似于 MySQL dump，mo-backup 则相当于 MySQL 的 extra backup。

为了方便部署和管理，我们也开发了一套名为 MOCTL 的自研工具。此外，与 MySQL 不同的是，MatrixOne 天然记录数据库相关日志和查询，便于监控。通过对接 Grafana 等可视化组件，可轻松实现监控功能，无需额外采集器。

总之，在开发和运维方面，MatrixOne 与 MySQL 具有很高的一致性，有助于降低迁移成本，提升工作效率。

在面向大数据领域开发时，会用到很多如 ETL 工具、计算引擎、BI 工具和数据调度等工具。为确保兼容性，我们已经对这些工具进行了适配，并在官方网站上提供了相关教程文档。

Part 3

MatrixOne 适用场景和最佳实践

接下来，简要总结一下 MatrixOne 适用于哪些场景。

MatrixOne 是一款超融合数据库，同时具备强大的云原生扩展性能力。其主要应用场景如下：

1. 事务处理（TP）：MatrixOne 可作为高性能的事务处理数据库，适用于需要高性能读写操作的场景。由于 MatrixOne 与 MySQL 语法接近，开发者无需额外学习即可上手。此外，MatrixOne 提供了更好的扩展性，支持分库分表，适用于需要分布式处理的场景。

2. 分析处理（AP）：MatrixOne 提供了高性能的 AP 能力，单机性能可与 ClickHouse 媲美，同时具备更好的扩展性。适用于需要高效报表查询、复杂分析以及 HTAP（混合事务处理和分析）的场景。

3. 时序数据处理：适用于 IoT 设备监控、互联网业务监控等场景，这些场景下数据量大、写入并发高，且需要实时查询性能。MatrixOne 可提供窗口函数、降采样等高级功能，满足此类场景需求。

4. SaaS/多租户应用场景：SaaS 应用需要具备扩展性、事务处理和应用处理能力，同时支持多租户。MatrixOne 支持多租户和自动扩容，适用于此类场景。

5. 实时数据仓库：适用于实时数据仓库场景。MatrixOne 具有高实时性，适用于需要快速处理海量数据的应用。

6. 数据中台：适用于轻量级主要面向结构化数据处理的数据中台场景。

7. 数据智能 AI：MatrixOne 支持实时 AI 处理，结合向量数据库技术，实现从数据处理、结构化到查询的一站式解决方案。通过融合 SQL 精准查询和大模型的模糊回答，MatrixOne 能提供更优秀的结果。

综上，MatrixOne 可广泛应用于事务处理、应用平台、时序数据处理、SaaS 应用、实时数据仓库、数据中台和数据智能 AI 等场景。

MatrixOn 的核心价值就是一站式。在 HTAP（混合事务处理分析）场景中，传统的 HTAP 系统通常包括一套事务处理（TP）数据库、一套 BI 系统和一套分析处理（AP）数据库，并通过 ETL 工具实现数据互通。然而，在 MatrixOne 的支持下，这一整套架构可以变得更加紧凑和高效。

很多时候，BI 系统是从业务系统中分离出来独立运作的，因为它在处理大量数据时，业务系统的 OLTP 数据库难以胜任。但实际上，BI 系统应该是业务系统的一个有机组成部分。在 MatrixOne 的支持下，HTAP 系统可以实现底层能力的整合，避免分裂为两套系统。

我们可以将业务系统和 BI 系统整合在同一个 MatrixOne 集群中，通过资源组实现隔离和扩容策略。当业务负载达到一定程度时，系统可以自动进行扩容。数据仍然存储在 S3 中，实现了数据的融合。同时，通过 MatrixOne 的分析能力，可以为不同业务分配专门的资源组，实现负载分离。这种解决方案既满足了数据融合的需求，又实现了业务之间的隔离。

SaaS（软件即服务）场景是 MatrixOne 应用的另一大领域。在 SaaS 系统中，通常包括用户面和控制面两个部分。用户面主要针对各自独立的用户，涉及租户隔离问题。传统 SaaS 系统中，租户数据共享或完全隔离两种方案各有弊端。共享实例会导致资源竞争，而彻底隔离则管理成本过高。

MatrixOne 提供了一种折中方案，通过数据库内部的租户隔离功能，实现数据和资源组的独立管理。在 MatrixOne 中，可以创建数据库租户，实现数据隔离。每个租户的数据空间相互独立，同时可以分配不同的资源组，并具备自动扩缩容能力。这样，各个租户既可以保持隔离性，又能独立进行资源扩展，降低了管理成本。

控制面涉及监控、日志、计费和统计等功能，传统应用中通常通过单独的数据库或大数据组件来满足这些需求。MatrixOne 可以将这些功能集成到一个集群内，通过不同资源组的形式来实现各种负载的分割。同时通过订阅发布机制，可以控制面与用户面可以进行高效数据交互，实现数据共享。

总的来说，MatrixOne 可以为 SaaS 系统提供高效、便捷的数据处理方案。它整合了多个数据库功能，简化系统架构，降低管理成本。同时，MatrixOne 支持租户隔离和资源自动扩缩容，确保系统性能和稳定性。通过订阅发布机制，MatrixOne 还能实现数据交互，满足 SaaS 应用的需求。

在 MatrixOne 中，我们同时关注时序和实时数据分析的场景。这两者虽然在侧重写入和查询方面有所不同，但整体架构相似。时序数据主要来源于 IOT 设备或监控系统，通过 Kafka 或其他消息队列写入数据库。另一方面，上游数据库（如 MySQL 或 TB 数据库）通过 ETL 过程将数据导入数据库。

MatrixOne 流处理框架针对 Kafka 提供了专用的 Connector，避免了额外引入 Flink 等组件。同时，我们可以为写入部分分配特定资源组，以应对大量并发写入或高频写入。由于资源组具有扩展性，写入任务能够得到有效承载。查询部分与之前提到的 AP 场景相似，根据业务需求划分资源组并赋予扩缩容能力。在中途涉及数据转换的场景中，MatrixOne 提供了实时流处理能力，可在数据流中间进行数据转换。这种方式涵盖了整个数据处理架构，实现从数据写入到查询的一体化解决方案。借助一套工具，MatrixOne 能够满足从数据写入、查询到后续 AI 相关处理的全部需求。

关于矩阵起源

矩阵起源是是业界领先的大数据及数据库管理系统（DBMS）技术和服务提供商，主要团队成员来自国内外知名科技公司，具备强大的创新能力。矩阵起源的目标是打造并使用世界一流的数据基础设施技术和产品，协助企业实现从信息化、数字化到智能化的转型和升级。矩阵起源在云计算、数据库、大数据及人工智能相关领域拥有核心竞争力，具备广阔的行业和国际视野以及前瞻性，能够快速有效的将先进技术在不同领域实用化并规模化扩展。

关于 MatrixOne

矩阵起源的核心产品 MatrixOne，是基于云原生技术，可同时在公有云和私有云部署的多模数据库。该产品使用存算分离、读写分离、冷热分离的原创技术架构，能够在一套存储和计算系统下同时支持事务、分析、流、时序和向量等多种负载，并能够实时、按需的隔离或共享存储和计算资源。MatrixOne 能够帮助用户大幅简化日益复杂的 IT 架构，提供极简、极灵活、高性价比和高性能的数据服务。

MatrixOrigin 官网：新一代超融合异构开源数据库-矩阵起源（深圳）信息科技有限公司 MatrixOne

Github 仓库：GitHub - matrixorigin/matrixone: Hyperconverged cloud-edge native database

关键词：超融合数据库、多模数据库、云原生数据库、国产数据库。