likes
comments
collection
share

PolarDB-MySQL调研报告一、业务现状 1.1 【任务数据查询】拓扑 1.2 【看课任务进度更新】拓扑 1.3

作者站长头像
站长
· 阅读数 43

一、业务现状

1.1 【任务数据查询】拓扑

PolarDB-MySQL调研报告一、业务现状 1.1 【任务数据查询】拓扑 1.2 【看课任务进度更新】拓扑 1.3

1.2 【看课任务进度更新】拓扑

PolarDB-MySQL调研报告一、业务现状 1.1 【任务数据查询】拓扑 1.2 【看课任务进度更新】拓扑 1.3

1.3 【RDS代理连接】拓扑

PolarDB-MySQL调研报告一、业务现状 1.1 【任务数据查询】拓扑 1.2 【看课任务进度更新】拓扑 1.3

二、痛点

1、【存储成本】冷热实例设计以及高峰期新增只读实例，同一份数据均会被冗余多份，存储成本高

2、【稳定性隐患】冷热实例数据通过DTS同步，今年6.5因任务表新增字段，引发热实例十几亿数据同步到冷实例，导致冷实例CPU持续飙高，最后通过人工启停DTS任务、调整DTS同步速率解决。思考：未来但凡动到表结构都需要考虑该影响面，DDL成本很高

3、由1.1的【任务数据查询】拓扑可知，冷热实例的查询路由规则与业务逻辑强耦合，意味着任务域的数据查询必须遵循作业域内部的业务逻辑，两业务域实际是从属的关系，在架构上的可扩展性不足，我们希望任务域能够和作业域解耦

4、由1.2的【看课任务进度更新】拓扑可知，计算看课进度需要先读取RDS里的看课时长，从准确性及严谨性的角度来讲，这是一个典型的需要强制读主的场景，因为如果读取的是只读实例的看课时长，一旦binlog同步延迟，会导致计算出来的看课进度不准。但考虑到强制读主会使绝大部分看课流量都打到主实例上，横向扩容将失去意义，因此我们实际并未采用强制读主。

但即便这样，在某些极端情况下，主实例的负载压力仍然无法通过横向扩容释放

由1.3【RDS代理连接】拓扑可知，在正常情况下：

主实例负载 = 写请求负载 + 强制读主请求负载 + 主实例读权重/(主实例读权重+只读实例1的读权重+只读实例2的读权重）* 读请求负载

只读实例1负载 = 只读实例1读权重/(主实例读权重+只读实例1的读权重+只读实例2的读权重）* 读请求负载

只读实例2负载 = 只读实例2读权重/(主实例读权重+只读实例1的读权重+只读实例2的读权重）* 读请求负载

在写入压力极大的情况下，一旦主实例与只读实例间的binlog同步延迟超过了【延迟阈值】，即使将主实例的读权重配置为0，也将退化成下面这种情况：

主实例负载 = 写请求负载 + 读请求负载

只读实例1负载 = 0

只读实例2负载 = 0

5、在当前的任务域数据架构下（见1.2【看课任务进度更新】拓扑），RDS主要服务于学生作业任务查询等OLTP场景，而ES主要服务于教师作业监管等OLAP场景，意味着我们需要存储和维护两套不同的数据体系才能满足所有用户的需求，架构的复杂度以及维护的成本都比较高

三、PolarDB-MySQL企业版

3.1 产品介绍

PolarDB-MySQL是阿里自研的云原生HTAP数据库，100%兼容原生MySQL的多个版本，包括MySQL 5.6、5.7和8.0。基于云原生架构、计算存储分离、软硬件一体化设计，为用户提供具备超高弹性和性能、高可用和高可靠保障、高性价比的数据库服务

3.2 产品架构

PolarDB-MySQL调研报告一、业务现状 1.1 【任务数据查询】拓扑 1.2 【看课任务进度更新】拓扑 1.3

PolarDB-MySQL的产品架构具有如下特点：

一写多读

PolarDB采用分布式集群架构，一个集群包含一个主节点和最多15个只读节点（至少一个，用于保障高可用）。主节点处理读写请求，只读节点仅处理读请求。主节点和只读节点之间采用Active-Active的Failover方式，提供数据库的高可用服务。

计算与存储分离

PolarDB采用计算与存储分离的设计理念，计算节点仅存储元数据，而将数据文件、Redo Log等存储于远端的存储节点。各计算节点之间仅需同步Redo Log相关的元数据信息，极大地降低了主节点和只读节点间的复制延迟，而且在主节点故障时，只读节点可以快速切换为主节点👉无感秒切。

读写分离

从根本上解决了MySQL读写分离无法解决的由于延迟导致的查询不一致问题。

高速链路互联

数据库的计算节点和存储节点之间采用高速网络互联，并通过RDMA协议进行数据传输，使I/O性能不再成为瓶颈。

共享分布式存储

多个计算节点共享一份数据，而不是每个计算节点都存储一份数据，极大地降低了用户的存储成本。基于全新打造的分布式块存储和文件系统，存储容量可以在线平滑扩展，不会受到单个数据库服务器的存储容量限制，可应对上百TB级别的数据规模。

数据多副本、Parallel-Raft协议

数据库存储节点的数据采用多副本形式，确保数据的可靠性，并通过Parallel-Raft协议保证数据的一致性。

3.3 能否解决我们的痛点

痛点1：【存储成本】冷热实例设计以及高峰期新增只读实例，同一份数据均会被冗余多份，存储成本高

能否解决：✔️【存算分离，新增只读节点时只需支付计算节点费用，大大降低扩容成本】

痛点2：【稳定性隐患】冷热实例数据通过DTS同步，今年6.5因任务表新增字段，引发热实例十几亿数据同步到冷实例，导致冷实例CPU持续飙高，最后通过人工启停DTS任务、调整DTS同步速率解决。思考：未来但凡动到表结构都需要考虑该影响面，DDL成本很高

能否解决：✔️【多个计算节点共享同一份存储，自然也就不需要进行数据同步，同时底层通过Parallel-Raft协议保证多副本间数据的一致性】

痛点3：冷热实例的查询路由规则与业务逻辑强耦合，意味着任务域的数据查询必须遵循作业域内部的业务逻辑，两业务域实际上是从属的关系，在架构上的可扩展性不足

能否解决：✔️【底层存储更换成PolarDB之后不会再有冷热实例的设计，自然就不存在该问题】

痛点4：极端情况下，主实例的负载压力无法通过横向扩容释放掉

能否解决：✔️

为什么能解决？

产生这个问题的根本原因是RDS是存算一体的，同一份数据在多份存储间需要通过binlog同步，但是当数据库负载很高时，例如对大表执行DDL（如加字段）操作或大批量插入数据的时候，延迟会比较严重，从而导致无法从只读实例读取最新数据。因此RDS的代理功能无法解决由于延迟导致的查询不一致问题。

PolarDB-MySQL调研报告一、业务现状 1.1 【任务数据查询】拓扑 1.2 【看课任务进度更新】拓扑 1.3

而PolarDB是存算分离的，计算节点仅存储元数据，数据文件、Redo Log等都存放在远端的存储节点。各计算节点间仅需同步Redo Log相关的元数据信息，极大地降低了主节点和只读节点间的复制延迟。

PolarDB-MySQL调研报告一、业务现状 1.1 【任务数据查询】拓扑 1.2 【看课任务进度更新】拓扑 1.3

PolarDB采用了异步物理复制方式实现了主节点和只读节点间的数据同步。主节点的数据更新后，相关的更新会应用到只读节点，具体的延迟时间与写入压力有关（一般在毫秒级别），通过异步复制的方式确保了主节点和只读节点间数据的最终一致。PolarDB提供了如下四种一致性级别，满足不同场景下对一致性级别的要求：

一致性级别RDSPolarDB
最终一致性✔️✔️
会话一致性❌✔️
全局一致性❌✔️
全局一致性（高性能模式）❌✔️

混合读写场景下各一致性级别的官方压测结果对比：

  • 测试环境

一个规格为8核32 GB的PolarDB MySQL版8.0版本集群版。

  • 测试工具

Sysbench

  • 测试数据量

25张表，每张表250000行数据。

  • 纵坐标qps：表示sysbench测试结果。
  • 横坐标threads：表示测试时使用的sysbench并发线程数。
  • RW：表示假设RO节点（只读节点）无法提供全局一致性读，所有的读写请求均发往RW节点（主节点）。
  • 全局一致性：表示由代理提供的全局一致性功能。
  • 全局一致性（高性能模式）：表示打开内核提供的全局一致性（高性能模式）。
  • 最终一致性：表示代理设置为最终一致性读，并且关闭内核提供的全局一致性（高性能模式）。

PolarDB-MySQL调研报告一、业务现状 1.1 【任务数据查询】拓扑 1.2 【看课任务进度更新】拓扑 1.3

可以看到，全局一致性（高性能模式）相较于最终一致性，集群整体性能损耗控制在10%以内，全局一致性可以在集群内实现数据的强一致，数据写入后在只读节点上立即可读。

各一致性级别的详细区别请参见一致性级别

总结一句话：依托于 全局一致性（高性能模式） ，PolarDB的 主节点负载压力能够通过横向扩容释放

痛点5：在当前的任务域数据架构下，RDS主要服务于学生作业任务查询等OLTP场景，而ES主要服务于教师作业监管等OLAP场景，意味着我们需要存储和维护两套不同的数据体系才能满足所有用户的需求，架构的复杂度以及维护的成本都比较高

能否解决：❓【PolarDB是一款HTAP数据库，从它的定位来看就是要同时支持OLTP和OLAP的，因此它底层做了大量的优化，比如并行查询、列存索引等来提升复杂分析查询的性能。但从我目前的预研情况来看，很多红利都有一些使用限制，比如对购买的polarDB集群配置以及mysql版本有要求，且PolarDB的OLAP查询性能到底如何，能否取代ES作为B端的OLAP引擎还有待论证。综上我们本次并没有打算把ES替换成PolarDB，但从长远来看，引入polarDB将为B端最终实现HTAP打下基础，随着我们对Polar使用的深入，相信它在OLAP领域的价值会在我们的业务场景中体现】

3.4 其他优势

3.4.1 Serverless

3.4.1.1 概述

提供跟随系统业务负载的动态弹性扩缩容能力。集群各节点可实现秒级纵向弹性以及横向只读节点扩展能力，充分利用集群购买的计算资源，降低业务成本。

PolarDB-MySQL调研报告一、业务现状 1.1 【任务数据查询】拓扑 1.2 【看课任务进度更新】拓扑 1.3

3.4.1.2 技术架构

PolarDB-MySQL调研报告一、业务现状 1.1 【任务数据查询】拓扑 1.2 【看课任务进度更新】拓扑 1.3

  • Serverless集群Proxy扩缩
    • Serverless集群的代理Proxy为Serverless形态，Proxy资源独立于计算节点弹性扩缩无需用户选择。
    • Serverless Proxy的计量单位是PCU，1个PCU约等于1核2 GB的资源，0.5个PCU约等于0.5核1 GB的资源。
  • Serverless集群计算节点扩缩
    • 主节点（RW节点）和只读节点（RO节点）全部为Serverless形态，随业务负载变化而弹性扩缩，并采用单可用区共享分布式存储。
    • Serverless集群计算节点的计量单位是PCU。每当主节点或只读节点扩展或收缩时，节点的PCU会随之增加或减少。1个PCU约等于1核2 GB，0.5个PCU约等于0.5核1 GB的资源
    • 扩缩按照0.5 PCU的增量进行，当前PCU越大，扩缩步长相对越大。
    • 可以设置单节点弹性扩缩的范围，以PCU为单位。系统每秒钟会监测一次计算节点的PCU。
  • Serverless集群存储扩缩

存储空间采用Serverless方式，购买时无需选择容量，随着数据增长而在线自动扩容，只按实际数据量所占的存储空间大小收费。

3.4.1.3 资源弹性扩缩容触发条件
  • 纵向扩展触发条件

PolarDB主要监控主节点和只读节点的CPU使用率、内存使用率和其他内核层面指标。在监控周期内，出现如下三种情况中的任意一种时，通常会触发Serverless资源纵向扩展：

    • 用户可以自定义CPU使用率的阈值（默认值为80%），当单节点的CPU使用率高于阈值时，会触发本节点资源扩展。
    • 当单节点的内存使用率高于90%，会触发本节点资源扩展。
    • 当只读节点的规格小于主节点规格的一半时，会触发只读节点资源扩展。例如，当只读节点的规格是4 PCU，主节点的规格是10 PCU时，会触发只读节点资源扩展到不小于5 PCU的规格。
  • 横向扩展触发条件

当只读节点已经纵向扩展到设定上限，集群中现有的只读节点的CPU使用率或内存使用率仍然满足纵向扩展的条件（CPU使用率高于自定义阈值或内存使用率高于90%），则会触发只读节点的横向扩展。

  • 资源收缩触发条件

当单节点的CPU使用率低于50%且内存使用率低于80%时，会触发本节点资源收缩。

3.4.1.4 费用

费用包括计算节点费用、存储容量费用、备份存储空间（仅超出免费额度时收费）费用和SQL洞察（可选）费用。具体请参见Serverless费用说明

3.4.1.5 核心优势
  • 高可用

多节点的架构保障了Serverless集群的高可用，服务等级协议SLA与普通集群相同，共同保证了Serverless集群的稳定运行。

  • 高弹性
    • 扩缩范围广

Serverless业内自动扩缩范围最广的云数据库，支持自动横向扩展，单集群支持0~1000核范围内的无感扩缩。

    • 秒级扩缩

从容应对业务负载突增，5秒完成探测，1秒完成扩展；同时在业务负载下降时，集群资源阶梯性自动释放。

    • 业务无感

扩缩过程业务无影响。

  • 数据强一致

支持高性能模式的全局一致性，在集群内实现数据强一致，数据写入后在只读节点上立即可读，性能与弱一致性基本一致。

  • 低成本

以计算能力（PCU）定价，真正做到按量付费，帮助客户节省成本。成本下降最高可达80%。

  • 免运维

扩缩版本升级、系统部署、扩缩容、报警处理等所有运维工作由阿里云专业团队完成，用户无感知，业务无影响，服务持续可用，真正免运维。

3.4.2 PolarDB for AI

3.4.2.1 背景

PolarDB-MySQL调研报告一、业务现状 1.1 【任务数据查询】拓扑 1.2 【看课任务进度更新】拓扑 1.3

在目前的数据驱动的智能应用中，数据、特征和模型仍处于割裂状态。首先，数据工程师通过手工编写流程进行数据清洗和数据集成；然后，算法工程师通过自定义的特征工程流程、模型训练脚本以及定时任务脚本进行周期性的生产特征和模型；最后，开发工程师负责模型的上线、稳定性保证和监控运维。

这就导致了不同系统之间会进行数据迁移，同一份数据可能在不同源之间冗余，进而出现数据不一致的问题，以及特征难管理、模型难升级等困境。除此之外，数据工程师、算法工程师和开发工程师的人力成本也是当前数据驱动的智能决策应用难以大规模落地的一个阻碍。

而PolarDB for AI可以为数据驱动的智能应用提供一站式的数据（包括：数据、特征和模型）服务来解决这种割裂状态，大大减少数据驱动的智能决策开发过程中的人力成本，从而走出当前的困境。

3.4.2.2 概述

PolarDB for AI是基于PolarDB MySQL版的一个数据库内的分布式机器学习组件。其基于云原生的体系架构，通过SQL语句的方式提供了支持机器学习的一系列MLOps，包括：创建模型、训练模型、查看模型状态、查看模型列表、模型评估和模型推理等能力；同时提供了一系列内置的机器学习和人工智能算法，包括：分类算法、回归算法和聚类算法等。基于MLOps和内置的模型（目前内置了两大机器学习模型：NL2SQL大模型和通义千问大模型），PolarDB for AI为数据驱动的智能应用提供了高效、可靠、方便的数据智能能力，打破了数据库和业务应用之间的系统墙，提供了基于数据库数据智能的一站式服务。

3.4.2.3 版本要求

若要使用PolarDB for AI功能，PolarDB MySQL版集群需满足如下要求：

  • 产品版本为企业版，系列为集群版。
  • 内核引擎版本需为8.0.1及以上。
  • 数据库代理版本（Proxy）需为2.7.5及以上。
3.4.2.4 使用场景
  • 问答机器人

问答机器人基于数据库中的内容，根据用户的业务场景，结合AI能力（对话控制、机器学习、自然语言理解等），打造适合企业的对话服务。问答机器人可以实现7×24小时在线服务，能帮助企业接待更多客户、提升客户满意度、提高工作效率和降低运营成本。是企业进行在线咨询、在线营销和在线服务的好帮手。

  • 搜索推荐

在传统的数据库中，用户的搜索能力通常基于数据库固有的全文检索能力，不支持自然语言类的检索需求（如语义检索、同义词匹配等）。采用PolarDB for AI中成熟的搜索解决方案，可以大幅度提升搜索的精确性。

3.4.2.5 向量检索
  • 概念

向量检索（Vector Search）是一种基于向量空间模型的搜索技术，它利用机器学习（尤其是深度学习）生成的向量来表示文本、图片、视频或任何类型的数据项。这些向量捕捉了数据项的语义信息和内容特征，使得能够通过计算向量之间的距离或相似性来进行高效且精确的搜索。

在向量检索中，数据项通常被转换为高维空间中的点，也就是向量。这种转换通常由诸如Word2Vec、BERT以及ResNet等预训练模型执行，这些模型能够将自然语言文本或者图像内容编码为固定长度的连续向量。一旦数据被编码，就可以使用向量之间的相似度度量（如余弦相似度、欧几里得距离等）来查找最相关的结果。

向量检索能够提供传统关键字搜索所不能提供的优势，主要包括：

    • 语义搜索：能够捕获查询和文档的深层语义信息，实现基于意图而非仅仅关键字的匹配。
    • 多模态搜索：支持跨越文本、图像和其他非结构化数据的搜索。
    • 高效检索：通过使用ANN技术，能够在大规模数据集上实现快速搜索。

向量检索正逐渐成为搜索引擎、推荐系统以及其他多种应用中的核心技术。例如，电商网站使用它来提升商品推荐的相关性，社交媒体平台使用它来提高内容发现的精确度等。

  • 案例：搭建以图搜图场景
CREATE TABLE image(
  id bigint(20) comment '主键id',
  image_address varchar(255) comment '图片存储地址', 
  type int(8) comment '图片类型，1:bmp格式 2:gif格式 3:jpeg格式', 
  primary key(id)
);

INSERT INTO image(id,image_address,type) values(1,'https://xxx/image.bmp',1);

/*polar4ai*/CREATE TABLE image_vector(
  id int,
  image_address varchar,
  image_address_vector vector_512,
  type int, 
  primary key(id)
);

其中，image_address_vector为向量类型字段，维度为512。可以根据实际场景，选择离线将图片向量化并写入向量表，或在线将图片向量化。

/*polar4ai*/SELECT * FROM predict(model _polar4ai_image2vec,SELECT id,image_address,type FROM image) 
with(
  primary_key='id',
  x_cols='image_address',
  mode='async',
  vec_col='image_address_vector'
) 
INTO image_vector;

其中，_polar4ai_image2vec为图片转向量模型，目前仅支持输出512维向量。primary_key为向量表主键字段。x_cols为存储图片地址字段。mode为图片写入模式。vec_col为向量表中存储向量的字段。

/*polar4ai*/SELECT * FROM predict(model _polar4ai_image2vec,SELECT 'http://xxxx/image.png') with();

/*polar4ai*/SELECT id,'distance(image_address_vector,[1,2,3,4,5……,512])' FROM image_vector WHERE type=1 LIMIT 10;

其他内容不过多展开，详细可查看PolarDB for AI

3.4.3 分区表

3.4.3.1 概述

PolarDB分区表完全兼容原生MySQL的语法和功能。同时，PolarDB分区表相对于原生MySQL进行了性能增强，支持丰富的分区类型及组合。

分区表是将一个大的逻辑表，按照分区规则分割成多个小的物理表， 大的逻辑表为分区表，小的物理表为分区，每一个分区在存储引擎上独立组织管理数据和索引。分区规则主要包括RANGE、LIST、HASH三种，需要指定分区键， 根据分区键字段的值按照这三种规则把数据划分到不同的分区。PolarDB还支持创建混合分区，可以将每个分区放在不同的存储引擎上。

混合分区原理如下图所示：

PolarDB-MySQL调研报告一、业务现状 1.1 【任务数据查询】拓扑 1.2 【看课任务进度更新】拓扑 1.3

Orders表做二级分区的示意图如下：

PolarDB-MySQL调研报告一、业务现状 1.1 【任务数据查询】拓扑 1.2 【看课任务进度更新】拓扑 1.3

3.4.3.2 分区表类型及使用说明

HASH

创建HASH分区表。把数据按照哈希规则打散到不同的分区上，支持表达式来对分区列的值进行处理。

CREATE TABLE sales_hash
(
  s_id        INT,
  dept_no     INT,
  part_no     INT,
  country     varchar(20),
  date        DATE,
  amount      INT,
  PRIMARY KEY(s_id)
)PARTITION by HASH (s_id)
PARTITIONS 7;

RANGE

创建RANGE分区表。按照范围边界分区，常用于按照时间边界进行分区。分区边界必须是递增的。

CREATE TABLE sales_range_columns
(
  dept_no     INT,
  part_no     INT,
  country     varchar(20),
  create_date        DATE,
  amount      INT
)
PARTITION BY RANGE COLUMNS(create_date)
(
  PARTITION p1 VALUES LESS THAN('2023-01-01'),
  PARTITION p2 VALUES LESS THAN('2023-02-01'),
  PARTITION p3 VALUES LESS THAN('2023-03-01'),
  PARTITION p4 VALUES LESS THAN('2023-04-01')
);

LIST

创建LIST分区表。枚举类型分区，需要把每个分区的分区键的值枚举出来，枚举值不能重复。

CREATE TABLE sales_list_columns
(
  dept_no     INT,
  part_no     INT,
  country     varchar(20),
  date        DATE,
  amount      INT
)
PARTITION BY LIST COLUMNS(country)
(
  PARTITION europe VALUES in ('FRANCE', 'ITALY'),
  PARTITION asia VALUES in ('INDIA', 'PAKISTAN'),
  PARTITION americas VALUES in ('US', 'CANADA')
);

LIST DEFAULT HASH

PolarDB在同一级别支持两种分区类型：LIST和HASH。前面是普通的LIST分区，不符合LIST分区规则的数据会放在DEFAULT分区里，DEFAULT分区如果有多个分区则根据HASH规则计算。LIST DEFAULT HASH分区类型常用在LIST VALUES分布不均匀以及无法全部枚举的场景。

集群版本需满足如下条件之一：

    • PolarDB MySQL版8.0.1版本且修订版本为8.0.1.1.34及以上。
    • PolarDB MySQL版8.0.2版本且修订版本为8.0.2.2.1及以上。

图示如下：

PolarDB-MySQL调研报告一、业务现状 1.1 【任务数据查询】拓扑 1.2 【看课任务进度更新】拓扑 1.3 

CREATE TABLE list_default_hash (
  a INT,
  b INT
)
PARTITION BY LIST (a)
(PARTITION p0 VALUES IN (1,2,3,4,5),
 PARTITION p1 VALUES IN (6,7,8,9,10),
 PARTITION pd DEFAULT PARTITIONS 3);
3.4.3.3 部分索引

概述

PolarDB MySQL版支持在分区表上创建部分索引（Partial Index），即索引可以只创建在分区表的某一个或多个分区上，而不需要在所有分区上同时创建索引，可以节省大量的存储空间。

适用场景

  • 使用订单表或日志表等业务场景

对于在使用订单表或日志表等业务场景下创建的分区表，通常会选择按照时间进行RANGE分区，但一般只对最新的一到两个分区进行频繁的查询，从需求角度来讲，仅在查询频繁的分区上创建对应的二级索引即可，但原生的MySQL等数据库只支持在所有的分区上创建相同的索引，虽然满足了热点分区的查询需求，但浪费了在分区上创建二级索引的空间。

针对以上场景，可以在分区表上创建部分索引，即只在热点分区上创建所需要的二级索引，既满足热点分区的查询需求，同时也节省了本来需要在所有分区上创建二级索引的空间。

  • 对历史数据进行查询和分析的场景

需要对历史数据进行查询和分析的场景，通常会选择按照时间进行RANGE分区。对于新创建的分区，需要快速的插入数据并进行简单的查询，而进行数据分析的大查询几乎都在历史分区上，为了满足对于历史分区的查询分析需求，需要创建多个二级索引。但分区上的索引越多，数据写入速度会越慢。

针对以上场景，可以在分区表上创建部分索引，即在热点分区上创建简单查询的二级索引，在历史分区上创建分析类查询的二级索引。根据不同的业务需求在分区上创建不同的索引，不仅保证了热点分区的插入性能，同时满足了在历史分区上的查询分析需求。除此之外，最大限度的节省了在所有分区上创建二级索引占用的空间。

CREATE TABLE orders
(
  order_id    INT,
  dept_no     INT,
  part_no     INT,
  country     varchar(20),
  date        DATE,
  amount      INT,
  Primary Key(order_id),
  KEY o_ind_dp(dept_no, part_no) (partition orders_202212),
  KEY o_ind_amout(amount, order_id) 
   (partition orders_202201,
    partition orders_202202,
    partition orders_202203,
    partition orders_202204,
    partition orders_202205,
    partition orders_202206,
    partition orders_202207,
    partition orders_202208,
    partition orders_202209,
    partition orders_202210,
    partition orders_202211
   )
)
PARTITION BY RANGE(month(date))
(
  PARTITION orders_202201 VALUES LESS THAN(2),
  PARTITION orders_202202 VALUES LESS THAN(3),
  PARTITION orders_202203 VALUES LESS THAN(4),
  PARTITION orders_202204 VALUES LESS THAN(5),
  PARTITION orders_202205 VALUES LESS THAN(6),
  PARTITION orders_202206 VALUES LESS THAN(7),
  PARTITION orders_202207 VALUES LESS THAN(8),
  PARTITION orders_202208 VALUES LESS THAN(9),
  PARTITION orders_202209 VALUES LESS THAN(10),
  PARTITION orders_202210 VALUES LESS THAN(11),
  PARTITION orders_202211 VALUES LESS THAN(12),
  PARTITION orders_202212 VALUES LESS THAN(13)
);
3.4.3.4 全局二级索引（GSI）

概述

PolarDB MySQL版支持在分区表上创建全局二级索引（Global Secondary Index，简称GSI）。使用全局二级索引可以实现透明分区表，即可以像使用单表一样使用分区表，大大减少分区键对分区表的使用限制。全局二级索引功能当前处于灰度发布阶段

背景

当分区表上只存在局部索引时，使用分区表因受到分区键的限制，会遇到一些棘手的问题，如下：

  • 查询条件不包含分区键时，查询数据需要扫描分区表上的所有分区，这将带来明显的读放大问题，且分区越多，读放大越严重。
  • 查询结果对索引字段有顺序要求时，即使局部索引中每个分区的数据是有序的，也无法保证跨分区查询的索引数据全局有序，可能会触发额外的全局排序操作。
  • 局部唯一索引必须包含全部的分区键，否则无法保证所有分区的全局唯一性约束。

PolarDB MySQL版的全局索引与局部索引相对，全局索引不分区，由全部分区的数据构建而成。所以，全局索引上的索引数据对全局的分区表有序，如果想创建全局唯一索引，索引字段不需要包含全部的分区键。

前提条件

集群版本需为PolarDB MySQL版8.0.2版本且修订版本为8.0.2.2.7及以上

使用限制

  • 全局二级索引仅支持在InnoDB引擎上创建的分区表，不支持混合分区表。
  • 全局二级索引不能为全文索引或空间索引。
  • 创建全局二级索引的表不支持生成列（Generated Column）【列存索引里的一个概念】。
  • 分区级别的DDL变更（新增RANGE或LIST分区除外）会导致已创建的全局二级索引失效，需要先删除表上所有的全局二级索引，再重建二级索引，或直接使用UPDATE GLOBAL INDEX语法重建二级索引。
    1. 创建以a字段为分区键的RANGE分区表t1，同时在b字段上创建全局索引k1。
CREATE TABLE t1(
  a INT PRIMARY KEY,
  b INT,
  INDEX k1(b) GLOBAL
) PARTITION BY RANGE (`a`)
(PARTITION p0 VALUES LESS THAN (5) ENGINE = InnoDB,
 PARTITION p1 VALUES LESS THAN (10) ENGINE = InnoDB);
  1. 2. 删除t1表上的p1分区并重建全局二级索引。
ALTER TABLE t1 DROP PARTITION p1 UPDATE GLOBAL INDEX;
3.4.3.5 分区表常见问题
  • 数据量下限：使用分区表对数据量的下限没有要求，空表也可以建分区表，但数据量太少没必要分区。
  • 数据量上限：当数据量超过64 TB时必须进行分区，因为PolarDB MySQL版单表的最大数据容量为64 TB。
  • 分区数上限：在满足分区不超过8192个的前提下，根据业务场景和数据量决定分区数。
  • 与传统的MySQL数据库不同，PolarDB MySQL版对大表的支持做了很多优化，线上集群有超过40 TB大小的单表（单表指非分区表），访问性能没有明显的下降。目前，对于64 TB以下的数据量也没有绝对要求必须要分区，用户可以综合考虑数据的增长和如何管理数据库比较方便来选择是否创建分区表。
  • 是否需要进行分区主要看数据所占的空间大小，但是业务上更多按照超过多少数据量（行数）进行分区，数据量跟数据单行的长度有关，具体情况具体计算。一般10亿行（单行1K字节）估算成1 TB，建议分区数据量可以参考10亿行（PolarDB MySQL版线上集群有百亿级数据量的单表，没有性能问题）。
  • 使用PolarDB MySQL版数据库是否需要分库分表？
    • 不需要。考虑使用分区表代替分库分表。PolarDB MySQL版是基于共享存储和一写多读的计算存储分离架构的集中式数据库，单分区或单表数据量最大64 TB，不必过早考虑分库分表。
  • 使用PolarDB MySQL版数据库，单张表数据量太大 ，想使用分表，如何使用？
    • 建议使用分区表。
  • PolarDB MySQL版中如果单表数据记录条数达到亿级，是否需要做分库分表？还是选择分区表？
    • 建议使用分区表。
  • 业务上估算单张表的数据量为2 TB，选择使用PolarDB MySQL版还是PolarDB-X？
    • PolarDB MySQL版单表最大支持到64 TB， 2 TB的数据量相对较小，所以推荐使用PolarDB MySQL版。因为数据量超过1 TB，建议使用分区表。
  • 使用PolarDB MySQL版分区，会不会导致性能下降？
    • 与单表相比，扫描相同的数据量（全表扫描），分区表的扫描有分区间切换的代价，会存在性能损耗。相同数据量的情况下，单表只有一个B+树，分区表是每个分区一个B+树，树的层级相对较低，insert性能会更好；分区表能使用where条件进行分区剪枝的查询场景可以减少数据的扫描和计算，性能也会更优；相对于分库分表，使用分区表在做JOIN、DDL时，性能上也有优势。
  • 分区数太多，导致内存耗尽，如何解决这个问题？
    • 在PolarDB MySQL版8.0.1和8.0.2版本中，不存在该问题，分区的内存都是共享的。建议升级内核版本。

更多常见问题👉分区表常见问题

3.4.4 冷数据归档

3.4.4.1 概述

集群中某些库表的数据几乎没有更新、插入和修改操作，且读取频率非常低，如果有降本需求，可以使用冷数据归档功能，将这部分数据转存至低成本的OSS上存储，以降低数据存储成本。

3.4.4.2 技术原理
  • 归档为CSV或ORC格式的技术原理图如下：

PolarDB-MySQL调研报告一、业务现状 1.1 【任务数据查询】拓扑 1.2 【看课任务进度更新】拓扑 1.3

    • 对于普通表，可以将冷数据归档为CSV或ORC格式并存储在OSS上，随后PolarDB节点可通过阿里云内网访问OSS上的数据。
    • 对于分区表，可以将冷数据归档为CSV或ORC格式并存储在OSS上，或在读写节点上创建DLM策略来自动归档冷数据。目前冷数据归档功能支持将分区表中的部分数据以OSS外表的形式归档至OSS，同时也支持将分区表中的部分分区直接转存至OSS。归档后的数据格式会转变为CSV或ORC格式并分成多个文件存储在OSS上，PolarStore中的这部分数据会被自动删除，存储费用也会随着存储空间容量的降低而减少。
    • 仅支持对InnoDB引擎上的分区表使用冷数据归档功能。
    • 归档后的表为混合分区表，不支持对混合分区表执行DDL操作。
    • 暂不支持对LIST DEFAULT HASH分区表的DEFAULT分区执行冷数据归档操作。
    • 暂不支持对HASH或KEY类型的分区表执行冷数据归档操作。
  • 归档为为IBD格式的技术原理图如下：

PolarDB-MySQL调研报告一、业务现状 1.1 【任务数据查询】拓扑 1.2 【看课任务进度更新】拓扑 1.3

与归档为CSV和ORC格式的文件不同。该方案是在InnoDB存储引擎下使用OSS，而不用修改表所在的引擎。仅通过归档语句手动将IBD格式文件的存储位置从PolarStore迁移至OSS。归档完成后，PolarStore中的这部分数据会被自动删除，存储费用会随存储空间容量的降低而减少。归档至OSS的IBD文件仍具有DML能力。且IBD格式的文件保留了原有的索引结构，因此归档后的IBD格式的文件仍具备原有索引能力。IBD格式不支持分区表归档。

3.4.4.3 版本要求
  • 归档为CSV或ORC格式的企业版集群的版本要求如下：
    • 当产品系列为集群版时，版本需为如下版本之一：
      • PolarDB MySQL版8.0.1版本且修订版本为8.0.1.1.31及以上。
      • PolarDB MySQL版8.0.2版本且修订版本为8.0.2.2.9及以上。
    • 当产品系列为多主集群（库表）时，版本需为PolarDB MySQL版8.0.1.0.13及以上。
  • 归档为IBD格式的企业版集群的版本要求如下：

PolarDB MySQL版的集群版需为8.0.1版本且修订版本为8.0.1.1.38或以上。

3.4.4.4 使用说明
  • 归档冷数据

需要先登录PolarDB控制台并开启冷数据归档功能，然后连接数据库集群，再执行冷数据归档操作：

    • 普通表：可以手动将冷数据归档为CSV或ORC格式并存储在OSS上。
    • 分区表：可以手动将冷数据归档为CSV或ORC格式并存储在OSS上，或在读写节点上创建DLM策略来自动归档冷数据。
  • 查询冷数据

对普通表和分区表执行冷数据归档操作后，可以通过以下方法查询归档后的冷数据：

    • 普通表：执行冷数据归档后，查询冷数据的方法和查询热数据的方法一致，不需要修改访问方式。
    • 分区表：执行冷数据归档后，查询冷数据的操作方法请参见查询混合分区。

由于归档后的冷数据为单表多文件格式，在查看冷数据时，可以采用并行查询进行查询优化，详情请参见基于OSS外表的单表多文件查询。

  • 修改冷数据
    • 修改CSV或ORC格式的冷数据。

如果有低频修改归档到OSS上冷数据的需求，可以通过ALTER ENGINE语法将OSS数据导回PolarStore进行修改。数据导回至PolarStore后，会同步删除OSS上的冷数据。修改完数据之后，可以再次将修改后的表归档为OSS表。详情请参见将OSS数据导回至PolarStore。

    • 修改IBD格式的冷数据。

与归档前的修改操作无差异，使用与冷数据归档前的SQL语句修改即可。

  • 删除冷数据

首先，需要使用DROP TABLE删除归档表，然后再通过CALL dbms_oss.delete_table_file('database_name', 'table_name');来删除归档后的冷数据。

3.5 数据迁移

3.5.1 升级方案概述

PolarDB支持将RDS MySQL一键升级至PolarDB MySQL版，整个过程中将自动创建目标端PolarDB集群并同步数据。升级后的PolarDB集群包含源RDS实例的账号信息、数据库、IP白名单和必要的参数。

可以将RDS MySQL迁移至相同或不同版本的PolarDB MySQL版。如RDS MySQL 5.6一键升级至PolarDB MySQL版 5.6，RDS MySQL 5.6升级至PolarDB MySQL版 8.0。

说明：RDS MySQL 8.0版本、RDS MySQL云盘版本一键升级至PolarDB MySQL版，以及RDS MySQL跨版本一键升级至PolarDB MySQL版，都是通过逻辑迁移（DTS数据同步）方式实现。

源RDS MySQL实例的计费类型不管是包年包月还是按量付费，都可以一键升级至PolarDB MySQL版，并且目标PolarDB集群的计费方式可以是包年包月、按量付费或是Serverless。

3.5.2 升级方案优势

一键升级功能具有如下优势：

  • 可保留数据库原连接地址，无需应用程序修改任何连接配置即可切换至PolarDB。
  • 迁移完全免费。
  • 迁移过程数据0丢失。
  • 支持回滚，迁移失败可以在10分钟内恢复。
  • 对于包年包月的RDS实例，数据从RDS迁移到PolarDB后，若业务已在PolarDB上稳定运行且不再需要RDS时，可以申请转单优惠退款，避免浪费闲置的RDS资源，详情参见包年包月RDS迁移至PolarDB后申请转单优惠退款。

3.5.3 前提条件

如果RDS处于高安全模式（数据库代理模式），需要创建有高权限账号（请参见创建账号），或者切换到高性能模式（参见【产品/功能变更】RDS网络链路升级说明），才能进行一键升级。

PolarDB-MySQL调研报告一、业务现状 1.1 【任务数据查询】拓扑 1.2 【看课任务进度更新】拓扑 1.3

3.5.4 迁移评估

为了保证迁移链路的顺利和更好的迁移体验，PolarDB提供了迁移评估功能，可以在开始迁移前，对实例状态、迁移任务依赖、源实例属性信息等前提条件进行预校验，提前发现影响迁移进度的前置条件并处理，以降低迁移过程中的处理成本和资源成本。具体操作说明，请参见迁移评估。

3.5.5 任务表迁移规则

来源表和目标表映射关系如下：

PolarDB-MySQL调研报告一、业务现状 1.1 【任务数据查询】拓扑 1.2 【看课任务进度更新】拓扑 1.3

分区键选型对比：

对比项用户ID学校ID
分区键类型hashlist default hash 或者 hash
优点1.分区数据量均匀，热点查询问题少2.查询足够简单，业务查询一定都会带上用户ID3.维护成本低，建立后基本不需要维护1.天然支持按单个学校维度的olap分析需求2.更符合租户的概念，长远来看，更贴近公司SaaS化的方向
缺点无1.学校的数据体量以及查询存在热点问题，即便大租户用单独分区存储，也面临着小租户未来会变成大租户的问题2.当前RDS源表并未冗余学校ID，且迁移后业务上的所有查询条件都需要带上学校ID，改造成本大3.需要考虑学生离校换校等业务场景，对应的数据需要做软删除
  • 源端的数据库中某张表是不分区的，通过DTS迁移到目标数据库中，需要对该表进行分区，是否支持？

支持，在数据同步任务中手动创建好分区表的结构，然后配置映射关系进行数据同步即可。

四、费用估算

4.1 选型

4.1.1 计费类型

计费类型包年包月按量付费Serverless
是否选择✔️❌❌
理由经济划算付费不划算Serverless不稳定

4.1.2 MySQL内核引擎版本

  • PolarDB for AI
    • 产品版本为企业版，系列为集群版
    • 内核引擎版本需为8.0.1及以上
  • 分区表类型（list default hash）
    • PolarDB MySQL版8.0.1版本且修订版本为8.0.1.1.34及以上
    • PolarDB MySQL版8.0.2版本且修订版本为8.0.2.2.1及以上
  • 列存索引
    • PolarDB MySQL版8.0.1版本，且修订版本为8.0.1.1.22及以上
    • PolarDB MySQL版8.0.2版本，且修订版本为8.0.2.2.12及以上

综上，选择 PolarDB MySQL版8.0.1版本

4.1.3 产品版本

功能特性功能描述企业版标准版
高压缩引擎（X-Engine）阿里巴巴自研的基于LSM-tree架构的存储引擎X-Engine提供了强大的数据压缩能力，满足了归档数据库低存储成本的要求。对比使用InnoDB作为存储引擎，最高可节省70%的存储空间。✔️❌
热备切换PolarDB提供了热备切换功能，可事先为集群中的只读节点开启热备功能，从而在主备切换的过程中实现快速切换和事务保持。✔️❌
全局一致性（高性能模式）PolarTrans事务系统利用提交时间戳技术CTS和RDMA网络，在内核层面提供全局一致性（高性能模式）服务，保证发往集群任意副本的读请求都可以获得强一致性的结果。✔️❌
冷数据归档若集群中某些库表的数据几乎没有更新、插入和修改操作，且读取频率非常低，如果有降本需求，可以使用PolarDB MySQL版提供的冷数据归档功能，将这部分数据转存至低成本的OSS上存储，以降低数据存储成本。✔️❌
PolarDB for AIPolarDB for AI功能通过一系列MLOps和内置的模型解决了数据、特征和模型的割裂状态，实现了基于数据库的数据智能的一站式服务。✔️❌

综上，选择 企业版

4.1.4 计算资源规格

子系列名称独享规格通用规格
描述独享计算资源，性能更稳定不同实例间的空闲计算资源会相互充分利用，更高性价比
是否选择✔️❌

4.1.5 是否开启存储热备集群

关闭存储热备集群

  • 仅在主可用区提供数据库服务，不提供存储热备集群能力，成本较低。
  • 在可用区整体故障场景时，故障恢复时间较长。

PolarDB-MySQL调研报告一、业务现状 1.1 【任务数据查询】拓扑 1.2 【看课任务进度更新】拓扑 1.3

开启存储热备集群

  • 数据分布在多个可用区内，主可用区和备可用区各保存一份完整数据，具有更高的SLA可靠性保障。
  • 所有计算节点暂时要求位于主可用区，备可用区的存储热备集群用于主可用区故障时进行故障切换。
  • 存储费用相比同规格关闭热备的集群来说贵一倍。
  • PolarDB开启跨可用区自动切换后，当主可用区故障（例如，主可用区所有计算节点同时故障）时，集群会自动进行主备可用区切换，备可用区中的备库升级为新的主库，恢复集群的可用性。

PolarDB-MySQL调研报告一、业务现状 1.1 【任务数据查询】拓扑 1.2 【看课任务进度更新】拓扑 1.3 、

注意：跨可用区切换是有损的，详见👉自动切换可用区

  • 跨可用区的数据复制方式：异步（默认）、半同步
    • 半同步模式：在事务提交时，需要等待此次事务产生的redo日志在跨可用区备份节点完成持久化后，才能返回事务提交成功。
    • 异步模式：在事务提交时，不需要等待此次事务产生的redo日志在跨可用区备份节点完成持久化，只需在RW上完成持久化就可以返回事务提交成功。
  • RPO（故障数据丢失量）和RTO（故障恢复时间）
    • 在异步场景下，跨可用区自动切换功能是有损切换（绝大部分情况下RPO < 100ms，最差情况下RPO < 60s），使用前请进行评估。
    • 在半同步场景下，开启后性能衰退约10%，默认事务提交等待时间是500ms，超过500ms就会退化为异步，不再等待同步至备可用区。无退化情况下RPO = 0。
    • 异步和半同步场景下的RTO < 30s。

综上，选择【 开启存储热备集群】

4.1.6 计算资源

RDS

平峰期：4个4c8g的热实例+1个4c8g的冷实例

高峰期：4个8c16g的热实例+4个8c16g的热只读实例+1个8c16g的冷实例

PolarDB

平峰期：1个16c64g的主节点+1个16c64g的只读节点

高峰期：1个32c128g的主节点+1个32c128g的只读节点

推算依据：

RDS标准版4c8g高可用系列独享型：最大连接数6000 最大iops20000

RDS标准版8c16g高可用系列独享型：最大连接数8000 最大iops25000

PolarDB企业版16c64g独享规格：最大连接数32000 最大iops96000（psl4）

PolarDB企业版32c128g独享规格：最大连接数64000 最大iops144000（psl4）

参考：

RDS实例规格参考文档

Polar计算节点规格参考文档

20240801任务域数据库峰值指标如下（当天峰值在线25.38w人）：PolarDB-MySQL调研报告一、业务现状 1.1 【任务数据查询】拓扑 1.2 【看课任务进度更新】拓扑 1.3

4.1.7 存储资源

4.1.7.1 存储类型
存储类型PSL5（PolarStore Level 5）PSL4（PolarStore Level 4）
特点PolarDB历史版本中支持的存储类型，即2022年06月07日之前购买的PolarDB集群默认的存储类型。性能好，可靠性和可用性更强。PolarDB全新推出的存储类型，采用阿里巴巴自研的硬件压缩盘（Smart-SSD）技术，在物理SSD磁盘层面压缩、解压缩存储的数据，保持性能影响可控的情况下，使单位容量数据的存储价格更低。
适用场景对性能和可靠性要求高，以数据库为核心系统的业务场景，如金融、电商、政务和大中型互联网业务等。有降低成本诉求，追求高性价比的应用场景。
费用2.27元/GB/月1.5元/GB/月
是否支持存储压缩不支持支持，且压缩后对性能无影响
最大IOPS（相同计算节点规格下，PSL4的IOPS上限为PSL5的一半）计算节点规格：16核64GB最大IOPS：192000* * *计算节点规格：32核128GB最大IOPS：288000计算节点规格：16核64GB最大IOPS：96000* * *计算节点规格：32核128GB最大IOPS：144000
读写性能总体性能差别不大，相比PSL5性能差异基本在10%以内
是否选择❌✔️
选择理由相比PSL5来说，性能差距不大，但费用会便宜很多，尤其是在开启存储压缩之后

性能对比

经过测试8核32 GB的独享规格集群的最大QPS，可以发现在IOBOUND负载模式下，PSL4和PSL5的性能差别不大，性能差异基本在10%以内。具体差异如下：

  • oltp_insert、oltp_point_select、oltp_read_only、oltp_read_write负载模式下，PSL4性能略低于PSL5；
  • oltp_update_index、oltp_update_non_index、oltp_write_only负载模式下，PSL4性能略高于PSL5。** **PolarDB-MySQL调研报告一、业务现状 1.1 【任务数据查询】拓扑 1.2 【看课任务进度更新】拓扑 1.3

说明

对于已创建的集群，存储类型不支持切换。如需切换存储类型，需要重新购买一个新的集群并配置预期的存储类型，将原有集群的数据通过外部迁移工具（如DTS）或PolarDB大版本一键升级功能迁移到新集群。具体操作请参见大版本升级。

4.1.7.2 存储空间

PolarDB只存储3年半数据， 过期数据不作归档直接删除，原因有两个：

  1. 过期数据在业务上没有使用场景；

  2. 分区表归档的限制非常多，对分区表的类型也有强限制（见3.4.4.2）；

按照3年半数据评估如下：

  • PolarDB容量预估（开启PSL4存储压缩前）：6~7 TB
  • PolarDB容量预估（开启PSL4存储压缩后）：2~3 TB

评估依据：

RDS热实例：InnoDB引擎，容量2.5 TB

RDS冷实例：X-Engine引擎，压缩后容量2.02 TB

PSL4与X-Engine的压缩比可以粗略评估相差不大，且迁移前我们还会清一波冷实例数据

4.2 费用

PolarDB和RDS每月折前费用对比：

PolarDB周期版本Mysql版本计算资源存储资源（开启存储热备）折前费用折后费用
配置数量费用存储类型容量费用
平峰期企业版8.0.116c64g1主1只读8000PSL43000G4500125007500
高峰期32c128g160002050012300
RDS周期版本Mysql版本实例实例资源存储资源单实例费用实例数总费用
配置费用容量费用
平峰期高可用5.7热实例4c8g9421000G16002542414310
冷实例4c8g9422000G320041421
高峰期热实例8c16g21841000G16003784434430.4
热只读实例8c16g1965.61000G15123477.64
冷实例8c16g21842000G320053841
DTS全年small51042040

RDS（4个热备+1个冷备实例）折后费用按月对比：

月份打折后费用（元）
7月19698.3
5月12423.59
1月12325.44
转载自:https://juejin.cn/post/7416527767141744674
评论
请登录