YMatrix

Version Release History
Platform Requirements

YMatrix

Quick Start

Standard Cluster Deployment

Data Modeling

Connecting to The database

Data Writing

Data Migration

Data Query

Maintenance and Monitoring

Performance Tuning

Troubleshooting

Reference Guide

SQL Reference

FAQ

scenario

YMatrix 架构

本文档介绍了 YMatrix 架构的以下内容：

  • 全局架构

    • 超融合架构
    • 数据库架构

  • 局部架构

    • 高可用架构

概述

YMatrix 为降低数据生态的复杂性，设计了具有超融合基因的简洁架构，将计算、存储和网络资源整合在一个统一系统中。其基于大规模并行处理（MPP）系统构建，符合微内核架构特点。

此架构可灵活、融合适应多个场景，不仅对于物联网时序场景友好，也支持传统分析型数据仓库环境及商业智能（BI）工作。

优势

使用超融合架构替换传统数据技术栈看似是一项艰巨的任务。那么，为什么我们一定要这样做？

实际上，无论在哪种情况下，全面使用超融合架构对于许多企业都能带来助益，为企业庞杂的 IT 系统提供统一的数据基座，包括智能网联汽车、工业互联网、智能制造、智慧城市、能源、金融、制药等。

相比于如 Hadoop 生态等复杂数据技术栈，YMatrix 架构有以下优势：

  • 超融合

    • 健壮性：一个复杂技术栈通常由 N 个单独的数据处理系统组成。假设任何一个组件出现故障的概率为 P，那么整个系统的稳定性可以近似看成是 (1-P)^N，即每多一个组件，稳定性都会大打折扣。超融合架构由于只有一个系统，自然最为稳定、健壮。
    • 经济性：因其超融合特性，YMatrix 可在单个系统中消费与管理数据，而无需在多个分布式系统间传递，避免了一份数据的多系统存储。物理硬件如磁盘等需求小，存储开销低。
    • 时效性：超融合架构中数据无需在多个系统间传递，延迟低，时效性高。
    • 简化管理：超融合方案使整个数据生态更容易管理，无需精通多种产品技术和程序语言，懂 SQL 即可操作。

  • 高可用

    • 在少数节点失效的情况下，YMatrix 的状态数据管理服务可以自动完成节点故障转移，无需人工参与，对业务透明。减少你的人工成本，降低人工风险。

  • 丰富的工具链生态

    • 兼容 Postgres / Greenplum 生态。覆盖数据迁移、写入、性能测试、备份、恢复等多种场景。

  • 支持标准 SQL

    • 支持 SQL：2016 标准，内容涵盖数据类型、标量表达式、查询表达式、字符集、数据分配规则、集合运算符等。

  • 完整支持 ACID 事务

    • 保证数据不重、不丢，保持数据一致，避免用户层复杂的错误检查处理，减少你的操作负担。

超融合架构

概述

与其他架构的数据库相比，YMatrix 的超融合体现在融合了多种数据类型与数据操作，从而在一个数据库内实现多种数据类型 + 多场景的高性能支持；就 YMatrix 内部架构而言，其具有微内核特征。在公共基础组件之上，为不同业务场景需求提供不同的存储、执行引擎组合，实现不同的微内核，以得到针对性的写入、存储、查询性能提升。

图解

下图描述了 YMatrix 内部的超融合架构组成及其功用：

以下部分详细介绍了 YMatrix 超融合架构的组成。

  • 公共基础组件 主要指数据库内部的公共资源，如内存管理、网络通讯包、基础数据结构等。
  • 存储引擎与执行引擎 指不同场景下 YMatrix 建表时可选用的存储引擎与执行引擎组合，每种组合可成为一个微内核。
  • 优化器 将 SQL 字符串转变为一个查询计划，根据选择的底层存储引擎提供的能力生成最好的计划。
  • 日志、事务、并发、锁管理、快照
    指 YMatrix 内核中提供并发控制，事务机制，故障恢复等通用功能的标准组件。
  • SQL 指 YMatrix 与客户端的标准 SQL 接口。
  • 认证、角色、审计、加密、监控、备份、恢复、高可用 指 YMatrix 支持的一些其他常见的数据库功能。

数据库架构

概述

YMatrix 的高层数据库架构在经典的 MPP（大规模并行处理）数据库技术架构基础上有所发展。

图解

下图描述了组成一个 YMatrix 数据库系统的核心组件以及它们如何一起工作：

以下部分详细介绍了 YMatrix 数据库系统中的各个组件及其功能。

  • 主节点（Master）
    • 负责建立与管理同客户端的会话连接。
    • 负责解析 SQL 语句并形成查询计划（Query Plan）。
    • 向 Segment 分发查询计划，监控查询执行过程，并收集反馈结果返回到客户端。
    • Master 不存储业务数据，只存储数据字典，即系统中使用的所有数据元素的定义及属性集合。
    • 在一个集群中，Master 只被允许有一个，可以采用一主一备，备用节点称为 Standby。
  • 数据节点（Segment）
    • 负责存储与分布式执行查询 SQL 语句。
    • 从 YMatrix 获得最佳性能的关键在于在大量能力相同的 Segment 之间平均地分布数据和工作负载，这样所有的 Segment 可以同时开始为一个任务工作并且同时完成它们的工作。
  • 客户端（Client）
    • 在此为泛称，泛指一切可以接入数据库的设备、客户端、应用程序等。
  • MatrixGate
    • MatrixGate 简称 mxgate，是 YMatrix 的高速流式数据写入工具，更多信息请见 mxgate。
  • 网络层（Interconnect）
    • 指数据库架构中的网络层，是 Segment 之间的进程间通信以及这种通信所依赖的网络基础设施。
  • 状态数据管理服务 （Cluster Service）
    • Cluster Service 通过对节点状态信息的管理保证了数据库的高可用。YMatrix 使用 ETCD 集群实现这一服务：当有一个数据库节点宕机时，ETCD 调用自身存储的节点状态数据信息，确认当前健康节点成为新的主节点，从而通过提升此节点来保障整个集群可用。
      例如，如果是 Master 宕机，则其 Standby 提升为 Master；如果是 Standby 宕机，则对整体集群无影响。同理，如果 Primary 宕机，则其 Mirror 提升为 Primary；Mirror 自身宕机对整体集群无影响。更多信息请见故障恢复。

高可用架构

概述

YMatrix 使用自研的 ALOHA（Advanced least Operation High Availability） 技术来保障集群的高可用性。当集群出现实例单点故障时，其对应的备用实例将发生角色切换，代替故障实例提供服务，从而保障了集群服务不中断。

故障节点实例影响时间
Mirror当 Mirror 故障，不会影响用户对于相应 Primary 中数据的查询，但需手动恢复故障的 Mirror网络通畅的情况下可达秒级别
Standby当 Standby 故障，不会影响用户集群数据的查询，但需手动恢复故障的 Standby
Primary当 Primary 故障，用户无法查询相应数据，需要等待系统自动提升对应的 Mirror 为 Primary 后再进行查询
Master当 Master 故障，集群不可用，用户无法查询相应数据，需要等待系统自动提升对应的 Standby 为 Master 后再进行查询

注意！
故障恢复详细操作步骤详见故障恢复。

原理

ALOHA 服务采用了基于 ETCD 集群的高可用架构。该架构可以解决故障自动转移（Failover）的问题，本质上来说即是实现自动选举主节点（Master）机制，并保持数据强一致性。

该机制包括以下环节：- Status data collection There are two sources of data reported to ETCD by the data cluster:

  • Regular detection and reporting regardless of whether there is a fault in the cluster or not
  • Cluster failure, service process is aware and reported - Status data storage The status data is stored in the ETCD cluster. ETCD is a mature distributed storage solution implemented based on the Raft protocol. As a state storage layer, it can provide reliable and unique cluster status information for process management and control in the event of a cluster failure.

Notes!
ETCD clusters will have more disk operations during storage state, so ideally, several separate physical machines should be used to deploy ETCD clusters, which can fully guarantee the performance of ETCD. However, in actual applications, the number of physical machines may not be enough to support ETCD independent deployment, so odd ETCD instances will be randomly deployed on some or all physical machines in the data cluster to save the status data of nodes and instances.

  • Process Control Based on the distributed and consistent storage provided by ETCD, the postmaster process of the service included in the API layer will obtain the status of each instance in real time. In this way, when a failure occurs, the roles of different primary and secondary instances will be scheduled instantly, thereby minimizing the impact of the failure.

The schematic diagram is as follows:

![](https://img.ymatrix.cn/ymatrix_home/High Availability Architecture Schematic Diagram_1715844707.png)

You can see:

  1. Clients such as management tools or MatrixUI send requests to the API layer;
  2. The API layer issues requests to the data cluster, and the data cluster provides state data for the API layer;
  3. The API layer reports cluster status data to the ETCD cluster, and can also read cluster status and service data from the ETCD cluster.

Appendix

ETCD

ETCD is a distributed key-value storage cluster used to store and retrieve data in a distributed system. ETCD uses Raft consistency algorithm to ensure data consistency and reliability. It is designed to be highly available with strong failure recovery capabilities. ETCD provides a simple RESTful API interface, allowing applications to easily access and manipulate key-value pairs stored there.

Important concepts:

  • Leader: The manager of the ETCD cluster is elected and unique.
  • Follower: Follower, synchronizes the logs received from the leader, and the default status is when ETCD is started.
  • Candidate: A candidate who can initiate a leader election.