client端 7.2 mds端 7.3 metaserver端 metaserver 子模块拆分 8、inode和dentry的内存估算 8.1 一台机器上能存放多少个inode和dentry 8.2 一台机器上建议的copyset数量 8.3 每个copyset建议管理存储容量的大小 1、背景 curvefs使用raft作为元数据一致性的保证。为了提高元数据的可扩展性和并发处理能力，采用元数据分片 每个元数据一定有对应的partition进行处理 inode manange/ dentry manager：负责管理元数据的内存结构 heartbeat：定期获取copyset的信息 模块 估算工作量（开发 + ci完成） client 10d mds 15d metaserver 10d 考虑到partition和copyset的多对一关系会带来开发商的复杂性，是否考虑先只实现p 5 增加copyset.proto 增加heartbeat.proto 增加topology.proto 8、inode和dentry的内存估算 类型 byte sizeof(dentry) 56 dentry的name字段，按照最大估算 256 sizeof(inode) 112 sizeof(volumeExtentList) 48 sizeof(S3ChunkInfoList)

什么是TiDB 产品优势 产品优势 ⾼度兼容 MySQL 动态扩展 分布式事务 HTAP 真正⾦融级⾼可⽤ 适⽤场景 适⽤场景 对数据⼀致性及⾼可靠、系统⾼可⽤、可扩展性、容灾要求较⾼的⾦融⾏业属性的场景 对存储容量、可扩展性、并发要求较⾼的海量数据及⾼并发的 OLTP 场景 Real-time HTAP 场景 数据汇聚、⼆次加⼯处理的场景 真正⾦融级⾼可⽤ UCloud 云上 云上 TiDB 架构⽰意图 架构⽰意图 Multi-Raft 协议 的⽅式将数据调度到不同的机房、机架、机器，当部分机器出现故障时系统可⾃动进⾏切换，确保系统的 RTO <= 30s 及 RPO = 0。 对存储容量、可扩展性、并发要求较⾼的海量数据及⾼并发的 对存储容量、可扩展性、并发要求较⾼的海量数据及⾼并发的 OLTP 场景 场景 随着业务的⾼速发展，数据呈现爆炸性的增⻓，传统的单机数据库⽆法满⾜因数据爆炸性的增⻓对数据库的容量要 命令修改副本数则会重新计算同步进度。 PROGRESS 字段代表同步进度，在 0.0~1.0 之间，1 代表⾄少 1 个副本已经完成同步。 步骤三 步骤三 使⽤ 使⽤TiFlash 同步完成后，TiDB 优化器会⾃动根据代价估算选择是否使⽤ TiFlash 副本。具体有没有选择 TiFlash 副本，可以通过 desc 或 explain analyze 语句查看，例如： desc select count(*) from

CPU，则会对集群 CPU 开销要求有 1:1 影响。否则，没有有关虚拟机所需 CPU 数量的具体 规则。 第 第 4 章 章 安装 安装 17 4.1.2.3. 存 存储开 开销 使用以下指南来估算 OpenShift Virtualization 环境的存储开销要求。 集群存 集群存储开 开销 Aggregated storage overhead per node ≈ 10 GiB 10 示例 示例 作为集群管理员，如果您计划托管集群中的 10 个虚拟机，每个虚拟机都有 1 GiB RAM 和 2 个 vCPU，集 群中的内存影响为 11.68 GiB。集群中每个节点的磁盘存储影响估算为 10 GiB，托管虚拟机工作负载的 worker 节点的 CPU 影响最小 2 个内核。 4.1.3. 对象最大值 在规划集群时，您必须考虑以下测试的对象最大值： OpenShift Container 虚拟机镜像可以托管在 HTTP 或 HTTPS 端点上，也可以内嵌在容器磁盘中，并存储在容器镜像仓库中。 重要 重要 当您将磁盘镜像导入到 PVC 中时，磁盘镜像扩展为使用 PVC 中请求的全部存储容量。要 使用该空间，可能需要扩展虚拟机中的磁盘分区和文件系统。 调整大小的流程因虚拟机上安装的操作系统而异。详情请查看操作系统文档。 8.16.2.1. 先决条件 先决条件 如果端点需要 TLS

采用多副本 + Multi-Raft 协议的方式将数据调度到不同的机房、机架、机器，当部分机 器出现故障时系统可自动进行切换，确保系统的 RTO <= 30s 及 RPO = 0。 24 • 对存储容量、可扩展性、并发要求较高的海量数据及高并发的 OLTP 场景 随着业务的高速发展，数据呈现爆炸性的增长，传统的单机数据库无法满足因数据爆炸性的增长对数 据库的容量要求，可行方案是采用分库分表的中间件产品或者 议使用 5.2.x 的最新版本。 在 5.2 版本中，你可以获得以下关键特性： • 支持基于部分函数创建表达式索引 (Expression index)，极大提升查询的性能。 • 提升优化器的估算准确度 (Cardinality Estimation)，有助于选中最优的执行计划。 • 锁视图 (Lock View) 成为 GA 特性，提供更直观方便的方式观察事务加锁情况以及排查死锁问题。 创建生成列或者 表达式索引时引 用自增列，默认 值为OFF。 tidb_opt_ �→ enable_ �→ correlation �→ _ �→ adjustment 新增 控制优化器是否 开启交叉估算， 默认值为ON。 tidb_opt_ �→ limit_push �→ _down_ �→ threshold 新增 设置将 Limit 和 TopN 算子下推 到 TiKV 的阈值， 默认值为100。

采用多副本 + Multi-Raft 协议的方式将数据调度到不同的机房、机架、机器，当部分机 器出现故障时系统可自动进行切换，确保系统的 RTO <= 30s 及 RPO = 0。 23 • 对存储容量、可扩展性、并发要求较高的海量数据及高并发的 OLTP 场景 随着业务的高速发展，数据呈现爆炸性的增长，传统的单机数据库无法满足因数据爆炸性的增长对数 据库的容量要求，可行方案是采用分库分表的中间件产品或者 表示所连接的 TiDB 服务器是否 启用了安全增强 模式（SEM），在 不重新启动 TiDB 服务器的情况下 不能改变该变 量。 tidb_enforce_ �→ mpp 新增 用于忽略优化器 代价估算，强制 使用 MPP 模式。 BOOL 类型，默认 值为 false。 tidb_ �→ partition_ �→ prune_mode 新增 用于设置是否开 启分区表动态裁 剪模式（实验特 TCP_NODELAY。 默认值为 true， 代表开启。 TiDB 配置文件 performance. �→ enforce- �→ mpp 新增 用于在实例级 别控制 TiDB 是 否忽略优化器 代价估算，强 制使用 MPP 模 式，默认值为 false。该配置 项可以控制系 统变量tidb_ �→ enforce_ �→ mpp 的初始 值。 TiDB 配置文件 pessimistic- �→

所期望的值。TiDB 采用多副本 + Multi-Raft 协议的方式将数据调度到不同的机房、机架、机器，当部分机 器出现故障时系统可自动进行切换，确保系统的 RTO <= 30s 及 RPO = 0。 • 对存储容量、可扩展性、并发要求较高的海量数据及高并发的 OLTP 场景 随着业务的高速发展，数据呈现爆炸性的增长，传统的单机数据库无法满足因数据爆炸性的增长对数 据库的容量要求，可行方案是采用分库分表的中间件产品或者 5 第 5 步：使用 HTAP 更快地分析数据 再次执行第 3 步中的 SQL 语句，你可以感受 TiDB HTAP 的表现。 对于创建了 TiFlash 副本的表，TiDB 优化器会自动根据代价估算选择是否使用 TiFlash 副本。如需查看实际是否 选择了 TiFlash 副本，可以使用 desc 或 explain analyze 语句，例如： explain analyze SELECT 语句需要执行的子任务。详见算子简介。 • estRows 为显示 TiDB 预计会处理的行数。该预估数可能基于字典信息（例如访问方法基于主键或唯一 键），或基于 CMSketch 或直方图等统计信息估算而来。 • task 显示算子在执行语句时的所在位置。详见Task 简介。 • access-object 显示被访问的表、分区和索引。显示的索引为部分索引。以上示例中 TiDB 使用了 a 列的

所期望的值。TiDB 采用多副本 + Multi-Raft 协议的方式将数据调度到不同的机房、机架、机器，当部分机 器出现故障时系统可自动进行切换，确保系统的 RTO <= 30s 及 RPO = 0。 • 对存储容量、可扩展性、并发要求较高的海量数据及高并发的 OLTP 场景 随着业务的高速发展，数据呈现爆炸性的增长，传统的单机数据库无法满足因数据爆炸性的增长对数 据库的容量要求，可行方案是采用分库分表的中间件产品或者 5 第 5 步：使用 HTAP 更快地分析数据 再次执行第 3 步中的 SQL 语句，你可以感受 TiDB HTAP 的表现。 对于创建了 TiFlash 副本的表，TiDB 优化器会自动根据代价估算选择是否使用 TiFlash 副本。如需查看实际是否 选择了 TiFlash 副本，可以使用 desc 或 explain analyze 语句，例如： explain analyze SELECT 保存时间，以避免增量同步时缺必要 binlog 导致重做。 说明：目前无法精确计算 Dumpling 从 MySQL 导出的数据大小，但你可以用下面 SQL 语句统计信息表的 data_length 字段估算数据量： /* 统计所有 schema 大小，单位 MiB，注意修改 ${schema_name} */ SELECT table_schema,SUM(data_length)/1024/1024

机 CPU 开 开销 如果请求专用 CPU，则会对集群 CPU 开销要求有 1:1 影响。否则，没有有关虚拟机所需 CPU 数量的具体 规则。 6.1.2.3. 存 存储开 开销 使用以下指南来估算 OpenShift Virtualization 环境的存储开销要求。 集群存 集群存储开 开销 Aggregated storage overhead per node ≈ 10 GiB 第 Example 作为集群管理员，如果您计划托管集群中的 10 个虚拟机，每个虚拟机都有 1 GiB RAM 和 2 个 vCPU，集 群中的内存影响为 11.68 GiB。集群中每个节点的磁盘存储影响估算为 10 GiB，托管虚拟机工作负载的 worker 节点的 CPU 影响最小 2 个内核。 6.1.3. 关于虚拟机磁盘的存储卷 如果您将存储 API 与已知的存储供应商搭配使用，则会自动选择卷和访问模式。但是，如果您使用没有存 虚拟机镜像可以托管在 HTTP 或 HTTPS 端点上，也可以内嵌在容器磁盘中，并存储在容器镜像仓库中。 重要 重要 当您将磁盘镜像导入到 PVC 中时，磁盘镜像扩展为使用 PVC 中请求的全部存储容量。要 使用该空间，可能需要扩展虚拟机中的磁盘分区和文件系统。 调整大小的流程因虚拟机上安装的操作系统而异。详情请查看操作系统文档。 10.16.2.1. 先决条件 先决条件 如果端点需要 TLS

所期望的值。TiDB 采用多副本 + Multi-Raft 协议的方式将数据调度到不同的机房、机架、机器，当部分机 器出现故障时系统可自动进行切换，确保系统的 RTO <= 30s 及 RPO = 0。 • 对存储容量、可扩展性、并发要求较高的海量数据及高并发的 OLTP 场景 随着业务的高速发展，数据呈现爆炸性的增长，传统的单机数据库无法满足因数据爆炸性的增长对数 据库的容量要求，可行方案是采用分库分表的中间件产品或者 5 第 5 步：使用 HTAP 更快地分析数据 再次执行第 3 步中的 SQL 语句，你可以感受 TiDB HTAP 的表现。 对于创建了 TiFlash 副本的表，TiDB 优化器会自动根据代价估算选择是否使用 TiFlash 副本。如需查看实际是否 选择了 TiFlash 副本，可以使用 desc 或 explain analyze 语句，例如： explain analyze SELECT 要查询的行数减少，往往查询速度也会非常快，而且所消耗的资源一般相对 TiFlash 而言会更少。 4.7.9.3.2 指定查询引擎 尽管 TiDB 会使用基于成本的优化器（CBO）自动地根据代价估算选择是否使用 TiFlash 副本。但是在实际使用 当中，如果你非常确定查询的类型，推荐你使用Optimizer Hints 明确的指定查询所使用的执行引擎，避免因为 优化器的优化结果不同，导致应用程序性能出现波动。

所期望的值。TiDB 采用多副本 + Multi-Raft 协议的方式将数据调度到不同的机房、机架、机器，当部分机 器出现故障时系统可自动进行切换，确保系统的 RTO <= 30s 及 RPO = 0。 • 对存储容量、可扩展性、并发要求较高的海量数据及高并发的 OLTP 场景 随着业务的高速发展，数据呈现爆炸性的增长，传统的单机数据库无法满足因数据爆炸性的增长对数 据库的容量要求，可行方案是采用分库分表的中间件产品或者 优化器引入更精准的代价模型 Cost Model Version 2 (GA) #35240 @qw4990 TiDB v6.2.0 引入了代价模型Cost Model Version 2 作为实验特性，通过更准确的代价估算方式，有利于最优 执行计划的选择。尤其在部署了 TiFlash 的情况下，Cost Model Version 2 自动选择合理的存储引擎，避免过 35 多的人工介入。经过一段时间真实场景的测试，这个模型在 5 第 5 步：使用 HTAP 更快地分析数据 再次执行第 3 步中的 SQL 语句，你可以感受 TiDB HTAP 的表现。 对于创建了 TiFlash 副本的表，TiDB 优化器会自动根据代价估算选择是否使用 TiFlash 副本。如需查看实际是否 选择了 TiFlash 副本，可以使用 desc 或 explain analyze 语句，例如： explain analyze SELECT