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

本文主要是介绍从 0 到 100TB，MatrixOne 助您轻松应对，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

作者：邓楠MO产品总监

导读

随着传感器和网络技术的大规模应用，海量 IoT 设备产生了巨量数据，传统数据库方案难以满足这些数据的存储和处理需求。MatrixOne 是一款强大的云原生超融合数据库，具备优秀的流式数据写入和加工能力，同时拥有强大的可扩展性，能适应任意规模的负载和数据量。接下来，矩阵起源产品总监邓楠老师将为大家分享从 0 到 100 TB，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 的核心理念就是超融合，即整合各类数据库的核心功能，满足用户最关心的需求。

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

分布式事务处理（OLTP）：支持高效的增删改查操作，满足流程交易型应用的需求。
分析性应用（OLAP）：提供强大的数据分析能力，帮助企业挖掘数据价值。
高速写入：支持大规模数据的快速写入，提升系统性能。
实时性：满足实时流处理需求，实现实时报表和分析预测。

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

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

社区版：开源免费，用户可以自由下载体验。
企业版：在社区版基础上增加了一系列运维工具和周边组件，便于企业级用户管理和运维。
公有云版本：完全托管的Serverless版本，即开即用，按使用量付费。

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

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

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

自动化资源供给：用户无需关心负载的变化，数据库会根据需求自动调整资源分配。
弹性扩展：根据负载情况，自动进行扩容和缩容，实现资源的动态调整。
按实际用量付费：用户只需为实际使用的资源付费。
免运维：Serverless 架构使运维工作变得更加简单，消除了节点管理带来的复杂性。
面向云设计：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 是一款超融合数据库，同时具备强大的云原生扩展性能力。其主要应用场景如下：

事务处理（TP）：MatrixOne 可作为高性能的事务处理数据库，适用于需要高性能读写操作的场景。由于 MatrixOne 与 MySQL 语法接近，开发者无需额外学习即可上手。此外，MatrixOne 提供了更好的扩展性，支持分库分表，适用于需要分布式处理的场景。
分析处理（AP）：MatrixOne 提供了高性能的 AP 能力，单机性能可与 ClickHouse 媲美，同时具备更好的扩展性。适用于需要高效报表查询、复杂分析以及 HTAP（混合事务处理和分析）的场景。
时序数据处理：适用于 IoT 设备监控、互联网业务监控等场景，这些场景下数据量大、写入并发高，且需要实时查询性能。MatrixOne 可提供窗口函数、降采样等高级功能，满足此类场景需求。
SaaS/多租户应用场景：SaaS 应用需要具备扩展性、事务处理和应用处理能力，同时支持多租户。MatrixOne 支持多租户和自动扩容，适用于此类场景。
实时数据仓库：适用于实时数据仓库场景。MatrixOne 具有高实时性，适用于需要快速处理海量数据的应用。
数据中台：适用于轻量级主要面向结构化数据处理的数据中台场景。
数据智能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架构，提供极简、极灵活、高性价比和高性能的数据服务。

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

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

这篇关于从 0 到 100TB，MatrixOne 助您轻松应对的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！