Skip to content

MatrixOne 功能特性

MatrixOne 特性

在 MatrixOne 版本 v25.2.1.0 中，具有如下特性，让你在使用 MatrixOne 的过程中更加高效：

分布式架构

在 MatrixOne 中，采用了分布式存算分离的分布式架构，存储层、数据层、计算层的分离，使得 MatrixOne 在遇到系统资源瓶颈时，能够灵活实现节点的扩容。同时，多节点的架构下，资源可以进行更加有效率地分配，一定程度上避免了热点与资源征用。

事务与隔离

在 MatrixOne 中，事务采用了乐观事务与快照隔离。

在分布式架构下，乐观事务可以通过较少的冲突获得更优的性能。同时在实现方式上，能够实现隔离级别更高的快照隔离。为了保证事务的 ACID 四个要素，MatrixOne 目前支持且仅支持快照隔离一种隔离级别。该隔离级别较常见的读已提交相比，隔离级别更加严格，既可以有效防止脏读，又能够更好地适配分布式乐观事务。

云原生

MatrixOne 是一款云原生的数据库，从存储层，适配本地磁盘、AWS S3、NFS 等多种存储方式，通过 File service 实现了对多种不同类型存储的无感知管理。MatrixOne 集群可以在多种基础设施环境下稳定运行，既可以适配企业私有云，又可以在不同的公有云厂商环境下提供服务。

负载均衡

在分布式数据库的架构下，不同节点之间不可避免地存在负载差异，可能导致某些业务场景的性能瓶颈或部分计算资源闲置。因此，MatrixOne 为确保不同节点在资源分配上尽量保持接近，实现了计算资源的负载均衡功能特性。

SQL 路由

SQL 路由常用于早期的分库分表数据库场景，用于在收到一条 SQL 请求后，根据数据分布情况，确定将该请求发送到哪个实例/库/表。

在 MatrixOne 中，虽然存储引擎的能力不再限制数据库规模，但在多 CN 的架构下，仍然存在着多 CN 之间负载均衡和不同租户之间资源隔离的场景需求。因此，在 MatrixOne 中，实现了 SQL 路由将 SQL 请求按照预定义的规则发送到不同 CN 节点执行，解决了一个数据库实例无法负载大量数据访问要求的情况。

白名单

白名单是一项安全策略，用于控制受限制的资源、系统或网络的访问。它基于一个核心思想，即只允许被授权和信任的实体进行访问，而拒绝其他未经授权的访问尝试。这些被授权的实体可能包括特定用户、IP 地址、程序或其他实体。与白名单相对的是黑名单，黑名单策略指定一系列被禁止的实体，这些实体将被阻止访问受限制的资源、系统或网络。在黑名单策略下，未被列入黑名单的实体可以进行访问。

白名单具有以下特性：

  • 只有预先定义的名单上的用户或系统才能被允许访问，其他未被列入白名单的用户或系统则被禁止访问。
  • 使用白名单策略可以提高安全性，但可能会限制合法用户的访问。因此，在实施白名单策略时需要权衡安全性和用户便利性。
  • 在数据库系统中，白名单主要用于限制用户访问，只允许特定用户在特定的服务器或网段上访问数据库，从而提高数据库的安全性。

多租户

单一集群多租户的方式可以提供资源共享、简化管理、提高可伸缩性、提供安全隔离等好处，对于需要同时为多个租户提供数据库服务的场景非常有价值。

MatrixOne 的多租户模式能够为不同的租户提供独立的数据库实例，并采用逻辑隔离的方式确保各租户数据的安全性和独立性，有效防止数据泄露和篡改的风险。

MatrixOne 性能优势

高效存储

MatrixOne 选择 AWS S3 作为一款高效的存储方案，满足了低成本和冷热数据分离这两个核心需求。其可靠的可用性保证了公有云中的低风险，并提供私有化部署的兼容版本。

  • 低成本：降低冗余度，获得性能可接受的更低成本。
  • 冷热数据分离：必要的条件，实现对数据的精细管理。

明确的事务分工

  • CN 负责所有的计算和事务逻辑，TN 负责保存元数据、日志信息和事务裁决。
  • 引入 Logtail 对象在日志中，用于保存最近日志中的关联数据。将 Logtail 的数据定期写入 S3 中。CN 扩容可以实时将 Logtail 数据同步至 Cache，实现部分数据共享。
  • 设置事务大小的阈值。超过阈值的事务直接写入 S3，日志只记录写入记录。未超过阈值的事务继续由 TN 写入，极大增加了吞吐量。

HTAP 工作负载隔离

作为 HTAP 数据库，实现了不同类型的工作负载隔离：

  • 服务器级别的隔离：在硬件资源充足的情况下，各个组件分别在不同的物理机运行，接入同一个对象存储。
  • 容器级别的隔离：在硬件资源有限的情况下，利用所有节点无状态的特性，以容器作为各个节点的隔离手段。

灵活的资源配比

作为 HTAP 数据库，不同业务场景的比例在不断动态变化，对资源的配比也有着更高的要求。旧架构下的资源分配模式注定无法实现灵活调整，需要对各个节点实现更加精细化的管理，包括但不限于：

  • CN 节点的分工：允许用户对 CN 进行划分，用于 TP 或 AP 业务。在某项业务资源出现瓶颈时，对 CN 进行水平扩容。
  • 动态判断不同业务 CN 组的负载情况，可以自动将闲置资源分配至繁忙组内。
  • 通过租户（account）的逻辑概念，实现逻辑资源的完全隔离。不同租户可以以独享或共享的方式使用指定 CN 资源。