活动回顾 | MatrixOne 在 SaaS 企服领域的应用解读

9月3日，矩阵起源产品总监邓楠于 QCon 北京站首次分享了 MatrixOne 在 SaaS 企服领域的应用，本篇文章将对该次分享进行回顾。

Part 1 MatrixOne 是什么？

MatrixOne 是一款面向未来的超融合异构云原生数据库管理系统。通过全新从零自研的统一分布式数据库引擎，能够同时灵活支持 OLTP、OLAP、Streaming 等不同工作负载的数据管理和应用，用户可以在公有云、自建数据中心和边缘节点上无缝部署和运行。

基于创新的HSTAP技术架构，MatrixOne 持续致力于打破数据孤岛，提供极简的“One Size Fits Most ”数据管理和开发应用解决方案。与传统的数据库方案相比，MatrixOne 不仅以灵活可扩展的架构将数据架构简化到极致，并且通过内置的流处理将用户从建立ETL管道的繁琐工作中解放出来，使得数据应用开发变得极为简捷，同时也确保了数据处理的极致性能。

从使用角度来看，MatrixOne与MySQL 8.0高度兼容。无论是连接、开发还是数据库管理工具，都可以无缝与MySQL 8.0进行兼容。如果你的MySQL相关应用是基于JDBC、Python或Golang的数据库连接器和ORM工具开发的，接入MatrixOne是轻而易举的。

Part 2 MatrixOne 应用场景

1. 业务分析一体化场景 ，举个例子，像ERP相关的软件，在发展到一定程度后通常需要结合报表系统或增强报表功能。以前的做法是使用两个数据库来支持，一个用于事务处理（TP数据库），一个用于分析处理（AP数据库），而现在只需使用MatrixOne即可解决这个问题。
2. 时序处理场景 ，该类场景简单来说，特点就是大量的高并发写入以及实时查询，常见于IoT系统，互联网运维监控/安全类系统，网络情报和爬虫类系统，这些场景都需要大量高频数据的写入和快速的分析，而这正是MatrixOne擅长的领域。
3. SaaS 应用 ，下文将会详细地分析 MatrixOne 解决SaaS 应用中的问题。
4. 实时数据仓库 ，实时数据仓库是OLAP数据库擅长的领域之一。MatrixOne在这个领域中提供了对事务、删除和更新以及高并发的支持，相比传统的OLAP引擎，具有更完整的能力。
5. 轻量级的数据中台 ，与传统的Hadoop方案对应。有很多传统的小型大数据系统，通常由十几个到二十几个节点的CDH构成，大多数已建立于5-8年前。从现在的视角来看，这些基于Hadoop架构的大数据系统的维护成本和数据处理能力已逐渐落后。如今，在美国几乎没有人再使用Hadoop来处理大数据，而大多数都转向了云原生化的数据平台。
6. 数据智能化应用 ，近期的热点话题，即基于大模型的数据应用。在这类的数据处理方面，我们也提供了一些解决方案。

Part 3 SaaS 应用设计中的常见挑战

接下来让我们一同来看一下 SaaS 应用设计方面存在哪些问题：

首先，来看一下SaaS市场的情况，参考了最新的36氪分析的中美SaaS市场对比报告。报告显示，近几年整个SaaS行业增速非常快，但就渗透率而言，中国的SaaS市场与美国相比仍存在一定差距。

在技术层面上，国内企业与全球化的SaaS企业之间存在一些差距。例如，在数据处理方面，国内许多行业垂直类的SaaS（如制造、能源、交通等实体行业）面临着巨大的数据压力，但目前的处理方案并不能很好地解决它们的问题，只能勉强应对。这实际上也是整个SaaS市场普遍存在的情况。

我们来简单回顾一下SaaS应用具备的基本特点。这里有四个关键点：

1. 网络化的供应：与以前的单体或私有化部署的软件不同，SaaS应用必须通过网络进行分发，并基于公网为用户提供服务。这意味着SaaS应用的规模通常要比传统的项目化软件大得多，会更容易碰到更多的IT系统问题。
2. 集中托管：SaaS应用在物理上是集中托管的，所有的组件都在一起。然而，对用户来说，每个账号的数据逻辑上都是独立的。因此，实现多租户架构对于SaaS应用非常重要。
3. 按需供应：SaaS应用注重订阅式收费模式，客户将会订阅产品和服务。一些SaaS产品会按模块进行销售，例如，某个客户订阅了A、B、C三个模块，另一个客户订阅了A、B、C、D、E五个模块，每个模块的收费是不同的。还有一些SaaS应用按使用量收费，例如一些提供API调用的产品。这就要求清晰地统计客户的SaaS使用量，并实时向客户反映这些用量。
4. 服务化：SaaS是一种长期订阅的产品，作为供应商，需要长期维护和升级产品。与一次性购买项目不同，SaaS客户的关系是长期的。没有续费的SaaS产品注定不会成功。因此，这些特点对于整个SaaS的技术架构能力提出了更高的要求，其中的数据处理能力也是一个巨大的挑战。

再来看一下目前非常典型的一个SaaS产品相关的架构。首先，从开发的层面上讲，SaaS软件通常需要每1-2周发布一个版本。因此，现在基本上有非常完善的 CICD 流水线，通过容器化的镜像服务来进行业务部署和应用开发环境。

另外则是支撑整个SaaS运行的技术架构。在前端方面，通常会有CDN、API网关、防火墙等组件。在整个应用层中，目前，大多数都采用了微服务化的方式，利用微服务框架（如Spring Cloud）和Kubernetes进行应用编排和调度管理。接下来是数据层，而这里就涉及到大量数据库组件的应用。首先，为了支持业务应用，通常需要使用MySQL或其他OLTP类数据库。此外，整个SaaS应用还需要专门的系统来管理日志、运维监控、性能分析、统计和计费等。这些系统可能会涉及到Prometheus监控、Elasticsearch日志处理和ClickHouse等OLAP数据库进行报表分析。最后，在SaaS应用中，各种系统模块的数据通常需要汇聚到所谓的数据中台中。目前，构建数据中台的主流方法仍然是传统的Hadoop体系中的组件，包括Hive、Spark和Flink等。另外，从今年开始，市场上出现了许多结合了人工智能的大模型应用，这可能还需要增加向量数据库。

在整个架构中与数据相关的部分占据了很大的比重。实际上，对于任何一家公司来说，处理这样的架构并不是一件容易的事情。在传统的软件开发模式中，通常需要建立一个规模很大的系统才能实现这样的架构。然而，对于SaaS来说，由于其在公网上提供服务，所以更容易在早期阶段就遇到数据压力的瓶颈。

这里有几个常见问题：

1. 当数据存储量增加后，分析数据变得困难。对于那些仍然只使用MySQL作为主要数据库的客户来说，这是非常常见的情况。一旦涉及到像报表这样需要复杂查询的操作时，他们可能会发现MySQL无法满足需求。通常来说，当MySQL的数据量超过1000万条或者达到几十GB时，查询性能就会大幅下降。
2. 写入吞吐量的需求很高。这在监控系统或运维软件中非常常见。如果需要进行计费或使用量统计等操作，会有大量的数据写入，这对普通关系型数据库来说是一项重大挑战。
3. 单表过长，需要进行分库分表。几乎每个SaaS在一定阶段都会面临这个挑战。随着数据量的增加，单个表可能变得非常庞大，此时就需要进行分库分表操作以提高性能和可扩展性。
4. 高并发性。作为云服务系统，整个SaaS的目标是增加用户数量，而用户数量的增加必然导致并发访问的增加，因此系统响应性能就成为一个重要问题。
5. 租户之间的相互影响。这在隔离性方面可能会带来很大的问题，如果没有考虑到适当的隔离措施，不同租户之间的操作可能会相互干扰。

>>> 针对每个问题我们详细拆解。

第一个问题是关于SaaS面临的挑战，即如何在数据层面实现多租户的隔离。通常来说，有两种核心选择方式：每个租户独占数据库实例，或多租户共享数据库实例，或介于两者之间。

第一种选择是每个租户都有一个专门的数据库实例。例如，如果有100个客户，就需要为每个租户分配一个单独的数据库实例。这种方式确保了很好的隔离性。但问题是，管理这100个数据库实例并不简单。对于每个实例的资源分配、性能监控和维护都需要投入大量的人力和成本。而且，随着租户数量的增加，这个工作会变得越来越困难。

另一种主流的选择是多个租户共享同一个数据库实例。在这种情况下，一个实例可以服务多个租户，通过tenantID将数据区分开。这种方式的管理成本较低，因为只需要一个实例。但是，它也存在一个很大的问题，即负载不均衡。由于租户的负载并不相等，当某个租户执行一个大型查询时，其他租户的查询性能可能会受到影响。因此，在隔离性方面存在一定的问题。

目前，许多用户都采用了一些中间方案，即一部分用户使用独立实例，一部分用户使用共享实例。然而，实质上它并没有根本解决这个问题。

第二个问题是可扩展性。事实上，几乎所有的SaaS公司都可以被视为相对较新的公司，它们的生命周期通常没有超过10年。这是因为云计算的发展时间有限，SaaS行业必然会面临各种问题——从初创阶段到成熟阶段，公司将遇到许多不同的挑战。

从ARR角度来看，一家初创公司一年可能只有数十万元的收入，团队也可能非常小，它可能会逐步成长到年入数十亿的规模，这可能已经是中国SaaS市场的顶峰了。

而在不同的发展阶段来说，数据规模和处理需求将有很大的差异。例如，在最初的SaaS场景中，可能只是一个单体应用程序，只有不到10个客户，因此只需使用一个MySQL主备数据库即可解决问题。

但当公司的规模达到10-100GB，并且客户数量达到10-100个时，情况就不同了。此时可能需要多个应用程序来满足客户需求，因此可能需要多个MySQL主备实例，并且需要进行分库分表。因为数据量已经增加，单个表无法满足要求，必须进行业务拆分以解决这个问题。

再往上发展到更大的，100-500个客户，这个阶段的客户，可以说中国的SaaS绝大多数还是集中在这个阶段，年收入在千万到亿元之间的一个阶段，相对成熟的一个SaaS公司。他们基本上现在业务已经微服务化改造，它现在基本上都要整个数据或者整个系统就要云原生化，云原生化现在第一步就是要买RDS，要把数据从以前自己在虚拟机里装的MySQL，换成一个RDS。相对来说有一定的扩展性，同时也还要做一些分库分表的操作。同时要开始会有一些日志监控甚至像计费相关的一些系统，这里面可能需要一套ES来去专门做这种管理。

再往后就是更大型，处于成熟阶段，拥有十亿以上的收入，实际上它需要增加很多的系统，包括计费、分析、报表一些大数据相关的系统，它的数据栈会变的非常复杂，类似于前面那一套非常完整的架构。ES加一个clickhouse，加一个Hadoop，加一个Spark，加一个Flink，管理难度是相当大的。那能不能有一套东西，从刚刚初创到最后解决这样一些数据架构上面的挑战呢？

第三个问题是实时性，这一点对于SaaS非常关键。就像互联网应用一样，如果实时性达不到要求，可能会导致客户流失并引发赔偿问题。由于SaaS是面向企业用户的应用，通常需要签订SLA协议，如果不能满足协议要求，将会造成严重后果。

实时性方面有两个方面需要考虑。

首先是业务应用的实时性，即对业务的增删改查操作的实时响应能力。这方面最担心的是高并发和大数据量的应用场景。

其次是数据分析的实时性。现在越来越多的SaaS厂商都设有自己的分析系统，比如内部的BI仪表盘，用于监测业务指标、用户数量等。对于内部系统来说，实时性要求并不太高，很多客户可以接受T+1或者T+N的延迟。但是随着SaaS分析能力的发展，解决方案不仅限于内部使用，还要提供给客户或合作伙伴使用。

举个例子，许多SaaS应用服务于电商、跨境电商等行业，比如ERP系统或CRM系统，其中的某些子系统并不仅仅是公司内部使用，而是提供给客户使用的。这意味着数据分析能力是SaaS的一部分，对客户来说，他们需要快速获取实时的分析结果，因为他们需要及时做出决策和运营行动，尤其是在营销和广告等领域。此外，SaaS中的计费、监控和运营模块也是如此。如果实时性不够高，可能会导致客户服务出现问题而未能及时察觉，比如客户已欠费几百或上千元，但平台仍没有终止他们的服务。

第四个问题是IT成本，SaaS平台的架构中包含了许多与数据库相关的组件，而数据库又是目前SaaS厂商必须使用的组件。如果要购买这些组件的全部版本，每年的费用至少达到几十万的规模。而这仅仅涉及到云资源方面的成本，还没有考虑到相关工程师的费用。因为运行这些组件需要专业人员进行配置和维护，然而这并非易事，因为每个组件都有其独特的技巧和门道。举例来说，将数据从一个数据库迁移到另一个数据库，以及维护所有的数据流程管道，这些都需要人力资源的投入。实际上，我曾经看到很多团队中有一半的工程师每天都在处理这些数据流程的维护工作，无法从事与业务相关的任务。所有这些成本都是相当惊人的。

第五个是异构部署。虽然对于SaaS来说，大家普遍认为应该放在公有云上，但在中国可能并非完全如此。实际上，我见过很多SaaS企业最初都是基于公有云的，但某些时刻它们会接到一些政企大客户的要求，这些客户通常需要私有化部署，而我们常说的企业级大客户则需要保证敏感数据的安全性。这时情况就变得有些棘手了，因为所有有用的东西、组件和整个工具链都在云上。若现在要进行私有化部署，就需要涉及到许多细节问题，例如如何将依赖于云的组件下放到本地环境中等等。

最后一个问题是智能化，也是现在最火热的话题。在大模型领域，人们普遍认为交互方式可能会发生一种转变，而对于SaaS来说，这种变化也十分明显。过去，交互是通过工作流和界面上的点击来完成的，而现在则完全基于自然语言进行交互，类似于通过对话框来完成任务。

在北美地区，像Tableau这样的数据分析类SaaS产品已经开始广泛应用与GPT相关的工具链。其中最常见的一种用法是将自有数据进行向量化，然后与大模型结合，通过结合大模型、向量数据库和Langchain等组件来实现。虽然这套技术相对较为成熟，但却增加了一个额外的数据组件，即向量数据库的管理。因此，你可能需要考虑如何将这个新的向量数据库与之前的整体架构进行结合。

Part 4 MatrixOne 技术特点及 SaaS 解决方案

MatrixOne 提供了相应的解决方案来解决SaaS所面临的技术挑战。

首先介绍一下MatrixOne的核心技术架构。MatrixOne是一个完全云原生化的产品，体现在以下3个方面：微服务架构、完全的存算分离、基于云上的成熟组件开发。

MatrixOne构建在两个主流云平台的基础组件之上。第一个是S3，即对象存储。另一个是Kubernetes (K8S)。在MatrixOne中，所有的组件都可以被理解为容器，可以快速地启动和关闭。作为容器，它们拥有强大的扩展能力，可以轻松地从一个容器扩展到多个容器，或者从小容器扩展为大容器。

我们将整个MatrixOne数据库的计算、事务和存储层进行了拆分，实现了一个三层解耦的架构。存储层完全基于S3对象存储，所有的数据都存储在对象存储中。在云计算领域，S3已经成为事实上的标准存储层，它拥有几乎无限的容量和自动扩展性，并且无需担心可靠性问题，AWS的S3可靠性达到了11个9。

在计算层，我们的计算节点称为CN，它是无状态的纯计算容器。可以根据需求轻松地扩展CN的数量，例如一次性扩展10个或100个。

在事务层，我们对Snowflake架构进行了创新改进。相比于Snowflake不支持TP（事务处理），我们的架构实现了事务能力。我们的事务处理组件称为TN，主要负责处理数据写入的仲裁和其他事务相关的处理。

此外，我们还有一个Log Service组件，用于记录最新的数据写入操作。我们会将最新写入的数据记录到Log Service中。当达到一定数据量后，后台会异步压缩数据，并将压缩后的数据写入S3中，这意味着S3中始终保存着完整的数据。

接下来简单介绍一下MatrixOne存储引擎，这也是矩阵起源完全自研的一套存储引擎。该存储引擎基于当前行业中流行的LSM Tree架构，并以列存为主。我们将所有的数据以column block的形式打包存储，并将同一表中的block全部放在一起，类似于PostgreSQL中的HEAP形式，从而实现了类似行存的一些功能。

我们的架构采用了多级冷热分离的存储设计，数据从上往下依次为热到冷。在CN节点中，我们设置了两级cache缓存，第一级是内存cache，第二级是本地磁盘cache。最热的数据存放在内存cache中，即最红色的部分；其次是整个disk的cache，它相对较冷，但容量稍微大一些。

第三个存储层是Log Service，即前面提到的日志层，它会少量使用EBS存储。尽管EBS的读取效率不如前两个存储层高，但它具有较高的可靠性和使用简便性，并且作为整个产品一致性的保障，其中包含三副本Raft协议。因此，它需要一定的可靠性来保证数据不会丢失。

最后一个存储层是对象存储的主存储，其容量可以做到无限大，可靠性非常高，达到11个9。然而，它的存取效率相对较低，这是一个缺点。我们将其作为主存储，仅在读取和写入比较大的数据块时直接与其交互，效果还是相当不错的。通过这种多级存储设计，用户需要读取数据时，会依次查看这些数据是否在相对热的存储层中。例如，对于TP数据，很多时候可以在热存储层中非常快速直接返回，这可以弥补云上对象存储存取效率较低的问题。此外，如果需要进行大数据量的写入或查询，可以直接从对象存储中访问，这样整个效率将保持相对平衡的状态。

为了实现HTAP，常见的技术路线有两种。第一种是像TiDB那样，使用两套引擎，一套用于处理事务性处理（TP），一套用于分析性处理（AP）。这种方法需要维护两份数据，并通过RaftLearner架构将TP引擎的数据同步到AP引擎。而我们的实现方式与此不同，它在同一数据引擎中只使用一份存储来实现HTAP。

我们的核心思想是有效拆分读写操作。对于写操作，我们将其处理过程几乎等同于处理TP问题。具体来说，当写入请求到达CN节点时，CN节点会将数据传递给TN节点。TN节点进行事务相关的判断，比如判断多个客户端写入的先后顺序，确定哪些需要等待，哪些可以立即写入。然后TN节点会将这些数据存储在我们的Log Service上，也就是说所有新写入的数据都会保存在这个位置，我们称之为LogTail。这些数据会被重新同步到服务查询的CN节点的内存中。因此，CN节点在处理查询时可以快速从缓存中找到相应的数据。

在查询方面，请求会经过Proxy到达CN节点。如果命中缓存中的数据，如LogTail，就可以在无需经过其他节点的情况下快速返回。缓存是一级一级地寻找的。如果未命中缓存，就会从S3读取数据。这种读取时至少读取一个匹配S3读取效率的数据Size，并将其放入缓存中，下次读取时可以直接从缓存中获取。

可以看出，在MatrixOne中，读和写的链路是完全不同的，并且在一个系统中，它们天生就是分离的。这种隔离性是实现整个HTAP的基础。

MatrixOne还内置了多租户能力，允许在其中创建多个账户（account）。每个账户天然地在数据空间上相互隔离，就像是拥有独立数据实例的数据空间一样。通过前端的代理（proxy）模块，我们可以灵活地自定义账户的资源组。也就是说，当使用accountA或accountB连接到MatrixOne时，它会被路由到相应的计算节点（CN组）。由于CN节点是无状态的纯计算模块，我可以通过打标签的方式，为account1分配一些CN节点，为account2分配另一些CN节点，这样在Kubernetes中可以保证它们的隔离性。

这意味着，如果通过account1进入前端，所有的连接都只会连接到account1对应的CN资源上；而account2则全部连接到account2对应的CN资源上。除此之外，在每个租户中，我们甚至可以进行更细粒度的资源组划分。例如，我们可以将备份负载和业务的增删改查负载进行拆分。实际上，你可以在代理上再设置标签，指定一些CN节点用于备份，另一些CN节点用于处理业务负载。

MatrixOne具备自动扩缩容的功能，可以通过感知负载来实现。MatrixOne内部集成了一套监控系统，用于存储各种运行状态数据。此外，我们还使用了云原生社区中著名的组件KEDA组件。KEDA会调用MO Scaler组件，后者会查询MatrixOne的负载相关指标。如果超过预设阈值，MO Scaler会向CN组发出扩容或缩容指令，实现scale out、scale in甚至scale to zero的操作。

这意味着，当租户完全没有负载时，可以关闭所有CN节点，不提供任何资源，就像关闭了自来水的龙头一样。对于那些对成本非常敏感的客户，比如SaaS场景，他们可以在没有负载时完全不花一分钱。

流计算是MatrixOne数据库中非常重要的内容。它主要解决两个问题。首先，我们需要从各种外部数据源（如其他数据库、日志系统、消息队列等）将数据写入到我们的系统中，这就需要一个流计算框架。通常行业内使用Kafka、FlinkCDC等组件来完成此任务。

我们在设计MatrixOne时，自己开发了一套Connector和流引擎系统，可以方便地接入其他数据库和外部组件（如Kafka），将包括数据库、消息队列和文件等各种外部数据都导入到MatrixOne中。

其次，流计算解决了内部数据处理的问题。也就是说，我们需要将原始数据转换为最终用于serving的数据，其中涉及到许多转换过程，比如聚合表、数据清洗和转化等。对于数据库而言，我们可以使用流计算提供的物化视图功能来解决这个问题。通过使用不同的算子，将数据的聚合和转换过程集成到流计算链路中，并最终生成物化视图。然后，我们可以将这些物化视图作为数据服务给业务应用。这样一来，就避免了许多用户目前所面临的复杂链路问题，即需要将原始数据读出，在外部使用Flink或代码进行处理，然后再写回数据库以供查询。

最后一个技术能力是MatrixOne正在研发的向量数据存储和计算功能，以满足智能化需求。向量数据类型本身并不复杂，许多通用数据库也开始支持向量存储，例如PostgreSQL的PGVector插件和Redis。然而，在处理大量向量数据时，搜索和过滤变得相对复杂。目前我们采用的方法是，针对写入向量的数据，通过异步调用相对空闲的CN，让它们专门构建查询索引。这样做的目的是减轻用户手动创建索引的负担，并在高负载情况下有效地处理向量搜索和过滤。

MatrixOne的以上技术特点对于SaaS有着重要的意义，解决了许多问题：

1. 它是一个单数据库的HTAP系统，意味着不再需要将业务和分析分开处理，不需要使用MySQL加上CK或Hadoop。现在只需要一个独立的数据库就可以解决这个问题。
2. MatrixOne具有无限的扩展性，无论是计算还是存储都可以进行无限扩展。这意味着无论是从公司刚成立的第一天开始，还是几年后处于成熟阶段或扩张阶段，都可以继续使用这个数据库，而不需要额外的工作。
3. 具备内置的多租户能力，这对于隔离性和整个管理负担的处理都非常有帮助。不需要在应用层面设计和拆分租户。
4. 具备自动扩缩容功能，当将租户拆分为不同的实例后，手动管理这些实例的扩缩容是一项巨大负担。但是通过自动扩缩容，这个问题得到了简化，无需手动管理容量相关的问题，尤其在云上。
5. MatrixOne完全符合云原生化的理念，对于部署也非常有帮助。即使需要进行私有化部署，现在许多客户环境都提供Kubernetes和对象存储环境，因此从云上迁移下来变得非常简单。此外，目前行业中已经有一些基于Kubernetes的数据库中间件，可以兼容公共云、私有云和多种Kubernetes发行版，这意味着只要使用它，从一个环境到另一个环境迁移将是完全无缝、非常简便的。
6. MatrixOne具备流计算能力，可以解决监控计费、日志处理等写入负载压力大以及自建ETL的负担。通过SQL就可以端到端地完成这些任务。
7. MatrixOne具备共享存储功能，所有数据都在一个地方，意味着最终只有一个数据副本加上一些对象存储的冗余能力。这带来了低廉的存储成本和数据一致性的保证，因为对象存储是云上最便宜的东西，而且没有数据移动，消除了对数据一致性检查的需求。因此，这种方法对于降低系统成本非常高效。
8. MatrixOne具备向量处理能力，如果想构建基于ChatGPT或其他大型模型的智能应用，可以直接使用它的向量能力，一键解决这个问题。此外，由于大型模型实际上主要解决的是文本数据处理的问题，可以对许多文本进行筛选和转化，同时在同一个应用中既可以使用SQL提取精确数据，又可以进行基于文本理解的综合答案生成，实现精确搜索和模糊搜索的混合搜索。

因此，MatrixOne在大型模型和传统应用结合方面具有很好的融合能力。

基于MatrixOne，如果要设计一套新的SaaS架构，可以按照以下方式进行。通常，整个SaaS可以分为用户面和控制面两部分。用户面是面向用户的，而控制面是用于内部管理的模块。

在用户面方面，我们可以有创建多个应用租户，每个应用租户对应一个独立的数据库租户Account，例如Account1、Account2、Account3，这样每个租户的数据空间就天然地被隔离了。同时，我们可以为每个数据库租户配置一个CNGroup资源组，并为其配备自动扩缩容策略。这样，每个租户在使用时不需要担心负载的问题，直接与资源组对应即可。

在控制面方面，我们可以使用另一个租户，即系统租户，用于管理控制界面的相关能力。同样地，我们可以为其设置计算资源的分组，例如为写入负载分配一个资源组，为分析相关任务分配一个资源组，为备份相关任务分配一个资源组。这些资源组可以存在于同一个账户中，意味着在一个用户空间中进行操作。这样的设计使得所有能力都具备可扩展性。如果现在系统租户和这些用户租户之间需要进行交互，例如平台层需要对用户相关数据进行统计或从中提取相关数据，我们可以使用发布-订阅机制，即从一个租户发布数据，另一个租户可以直接接收，因为它们本质上在同一个集群中。

总之，我们提供的这套实践架构实现了超融合的理念，所有的数据处理都集中在一个数据库中解决，而且使用起来与使用MySQL基本没有区别。

Part 5 用户案例

有一个典型的多租户问题场景，是一个ERP的SaaS厂商。这个厂商是某个制造领域的IT服务商龙头，目前有近5000个客户。他们目前的架构是通过多租户的形式，使用了十几个MySQL实例来支撑，每个实例大约有300个客户，采用了分库分表的方式进行资源共享和隔离。然而，他们面临着很大的隔离性问题。单个实例中的一些表已经达到了百万级别，而在ERP业务中，经常需要对多个大表进行复杂查询操作。这对整个数据库实例来说是一个巨大的负担，即使一个用户执行这种操作，其他用户也会受到影响。这导致了用户投诉和退款的问题，对业务产生了严重影响。

为了解决这个问题，我们可以将每个租户作为独立的实例部署到MatrixOne上。这样，每个实例之间天然具有隔离性，一个租户出现问题不会影响其他租户。同时，MatrixOne可以自动进行扩缩容，无需手动管理每个实例的资源。此外，如果需要在平台层面对这些用户进行管理和操作，所有实例都位于同一个集群中，可以方便地访问整个集群和其他租户的相关数据。

另外一个案例相对比较新，这是一个SaaS平台，基于大模型做数据服务。该平台利用公网上的大量数据，包括新闻和其他公开数据，提供舆情相关应用并为企业客户提供分析服务：会分析哪些新闻有利于客户，哪些不利于客户。该平台采用了一套复杂的数据架构。首先，他们将所有数据存储在MySQL中，这是主数据库。然后，他们使用自己开发的NLP算法来提取文本相关的信息，并将其转化为向量。这些向量被存储在一个开源的Faiss向量数据库中。此外，该应用还产生了一些半结构化的数据，这些数据被存储在MongoDB中。该平台还需要实现报表和统计相关的分析功能，因此他们还引入了ClickHouse。此外，还需要使用ChatGPT相关的接口来控制整个链路。最后，由于平台需要文本搜索和图计算能力，还加入了ElasticSearch和Neo4j。虽然该团队不到5个人，但是他们用了超过5个数据库组件，因此维护该系统变得非常困难。但是，如果采用MatrixOne，可以将MySQL、ClickHouse、MongoDB和Faiss的能力全部统一到一个数据库中，从而快速打造一个大型模型相关的应用。

---

MatrixOne社区介绍

MatrixOne是一款面向未来的超融合异构云原生数据库管理系统。通过全新设计和研发的统一分布式数据库引擎，能够同时灵活支持OLTP、OLAP、 Streaming等不同工作负载的数据管理和应用，用户可以在公有云、自建数据中心和边缘节点上无缝部署和运行。

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

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