TiDB 新版本 Meetup 活动中 TiDBer 最关心的 8 个问题

2024-10-11
北京
本文字数：6405 字
阅读完需：约 21 分钟

作者： Billmay 表妹原文来源：https://tidb.net/blog/31b400ba

问题 1: 列存储是不是比普通 OLTP 数据库占用更多空间？

TiDB 的 TiFlash 列存储通常不会比传统的 OLTP 数据库占用更多空间。实际上, 在许多情况下, 列存储可能会占用更少的空间。以下是一些关键点:

数据压缩效率: 列存储通常能够实现更高的数据压缩率。因为同一列中的数据往往具有相似的特征, 这使得压缩算法可以更有效地工作。
索引存储: 在 OLTP 数据库中, 索引通常会占用大量额外空间。而列存储由于其结构特性, 可能不需要像 OLTP 数据库那样多的索引。
数据冗余:TiDB 的列存储实现 (TiFlash) 确实会创建额外的数据副本, 这会增加一些存储开销。但这种额外开销通常被列存储的高效压缩所抵消。
存储效率与查询类型: 对于分析型查询, 列存储通常更加高效。对于 TPCH 类的负载，通过引入 TiFlash，投入对应的 TiFlash 节点基础上，预计增加 5~15% 的存储空间，节省 75% 的执行时间。
灵活性:TiDB 允许用户选择性地为某些表启用列存储, 这意味着你可以根据具体需求来平衡存储空间和查询性能。

总的来说, 虽然列存储可能会因为创建额外的数据副本而增加一些存储开销, 但其高效的压缩和针对分析查询的优化通常会抵消这种开销, 甚至在某些情况下会减少总体存储空间的使用。

另外，TiDB 存储节点在后台会自动发起数据整理（Compaction）。数据整理时，表中的物理数据会被重写，如清理已删除的数据、合并多版本数据等，从而可以获得更高的访问性能，并减少磁盘空间占用。使用 ALTER TABLE ... COMPACT 语句可以立即对指定的表进行数据整理，而无需等待后台触发。该语句执行时不会阻塞现有 SQL 语句的执行或 TiDB 功能的使用，包括事务、DDL、GC 等，也不会改变通过 SQL 语句访问获得的数据内容。该语句执行时会消耗一定量的 IO 及 CPU 资源，请注意选择合适的时机执行，如资源空闲时段，避免对业务造成负面影响。

该语句会等待表中所有副本都数据整理完毕后才结束运行并返回。在执行过程中，你可以通过 KILL 语句安全地中断本张表的数据整理过程。中断不会破坏数据一致性或丢失数据，也不会影响后续重新发起或自动触发后台数据整理。

🌟 参考材料

https://docs.pingcap.com/zh/tidb/stable/sql-statement-alter-table-compact#alter-table--compact

https://docs.pingcap.com/zh/tidb/stable/tiflash-overview

问题 2: TiDB 会出真正的多租户架构吗？

多租户架构场景，TiDB 会持续提升使用和管理体验。TiDB 产品方向上，希望通过动态调整，在保证集群服务 SLA 的前提下，尽量充分使用资源，达到降低硬件成本的目的。

TiDB 已经在 TiDB v7.1.0 版本中支持资源管控技术，这项技术可以在负载剧烈变化时保证服务质量，并提供了数据库的多租户隔离能力，有效降低数据库运行成本。资源管控技术通过在 TiDB 层进行流控和在 TiKV 层进行优先级调度，实现了资源隔离和服务质量 (QoS) 的保证。

此外，TiDB 多租户技术支持用户级别、会话级别和语句级别的资源绑定，使得不同业务的负载可以相互隔离，互不干扰，同时提升资源使用效率。通过为不同的业务设置不同的资源组和 RU（Request Unit），可以在集群资源繁忙时实现不同业务基于 RU 的限流和负载隔离。对于重要业务，可以设置资源组的 BURSTABLE 属性，允许在系统负载较低时超过设定的读写配额，从而最大化资源利用。

资源管控特性的引入对 TiDB 具有里程碑的意义。它能够将一个分布式数据库集群划分成多个逻辑单元，即使个别单元对资源过度使用，也不会挤占其他单元所需的资源。利用该特性：

你可以将多个来自不同系统的中小型应用合入一个 TiDB 集群中，个别应用的负载升高，不会影响其他业务的正常运行。而在系统负载较低的时候，繁忙的应用即使超过设定的读写配额，也仍然可以被分配到所需的系统资源，达到资源的最大化利用。
你可以选择将所有测试环境合入一个集群，或者将消耗较大的批量任务编入一个单独的资源组，在保证重要应用获得必要资源的同时，提升硬件利用率，降低运行成本。
当系统中存在多种业务负载时，可以将不同的负载分别放入各自的资源组。利用资源管控技术，确保交易类业务的响应时间不受数据分析或批量业务的影响。
当集群遇到突发的 SQL 性能问题，可以结合 SQL Binding 和资源组，临时限制某个 SQL 的资源消耗。

此外，合理利用资源管控特性可以减少集群数量，降低运维难度及管理成本。

🌟 参考材料

https://docs.pingcap.com/zh/tidb/stable/tidb-resource-control

https://zhuanlan.zhihu.com/p/708599710

问题 3: 如果存入节点存储节点很多，在跑分析 SQL 运行的是时候，会有大量数据回流到 TIDB Server，当时 TiDB Server 的网卡被打爆，然后体感就是 TiDB 响应慢了，在现有硬件资源的约束下，如何缓解这种情况

TiDB 产品迭代演进中，致力于高效精准解决这类问题。所以在 v8.1 LTS 支持 Runaway Queries 的能力，可以通过 Runaway Watch 持续关注检测异常 SQL 进行限流设置。

Runaway Query 是指执行时间或消耗资源超出预期的查询（仅指 SELECT 语句）。下面使用 Runaway Queries 表示管理 Runaway Query 这一功能。

自 v7.2.0 起，TiDB 资源管控引入了对 Runaway Queries 的管理。你可以针对某个资源组设置条件来识别 Runaway Queries，并自动发起应对操作，防止集群资源完全被 Runaway Queries 占用而影响其他正常查询。你可以在 CREATE RESOURCE GROUP 或者 ALTER RESOURCE GROUP 中配置 QUERY_LIMIT 字段，通过规则识别来管理资源组的 Runaway Queries。
自 v7.3.0 起，TiDB 资源管控引入了手动管理 Runaway Queries 监控列表的功能，将给定的 SQL 或者 Digest 添加到隔离监控列表，从而实现快速隔离 Runaway Queries。你可以执行语句 QUERY WATCH，手动管理资源组中的 Runaway Queries 监控列表。

为了避免并发的 Runaway Query 过多导致系统资源耗尽，资源管控引入了 Runaway Query 监控机制，能够快速识别并隔离 Runaway Query。该功能通过 WATCH 子句实现，当某一个查询被识别为 Runaway Query 之后，会提取这个查询的匹配特征（由 WATCH 后的匹配方式参数决定），在接下来的一段时间里（由 DURATION 定义），这个 Runaway Query 的匹配特征会被加入到监控列表，TiDB 实例会将查询和监控列表进行匹配，匹配到的查询直接标记为 Runaway Query，而不再等待其被条件识别，并按照当前应对操作进行隔离。其中 KILL 会终止该查询，并报错 Quarantined and interrupted because of being in runaway watch list。

此外，TiDB Server 网卡被打爆，需要看具体打爆原因。TiDB 的 SQL 优化逻辑是将查询算子、函数等下推到多个 TiKV 节点，最终在 TiD 吧 Server 汇聚输出。在 v8 版本，TiDB 默认允许将 Projection 算子下推到存储引擎，Projection 算子下推可以将负载分散到存储节点，同时减少节点间的数据传输。这有助于降低部分 SQL 的执行时间，提升数据库的整体性能。

🌟 参考材料

https://docs.pingcap.com/zh/tidb/stable/expressions-pushed-down# 下推到 -tikv- 的表达式列表

https://tidb.net/blog/d3d4465f 【 SOP 】 最佳实践 之 TiDB 业务写变慢分析

问题 4:TiFlash 后续会增加编组 group 的概念吗？希望部分 SQL 走 tiflash-g2，部分 sql tiflash-g2，即纵向的资源隔离

TiDB 在 v7.1 版本支持 Resource Control 资源管理器功能，从 v7.4.0 开始，TiDB 资源管控特性支持管控 TiFlash 资源，其原理与 TiDB 流控和 TiKV 调度类似：

TiFlash 流控：借助 TiFlash Pipeline Model 执行模型，可以更精确地获取不同查询的 CPU 消耗情况，并转换为 Request Unit (RU) 进行扣除。流量控制通过令牌桶算法实现。
TiFlash 调度：当系统资源不足时，会根据优先级对多个资源组之间的 pipeline task 进行调度。具体逻辑是：首先判断资源组的优先级 PRIORITY，然后根据 CPU 使用情况，再结合 RU_PER_SEC 进行判断。最终效果是，如果 rg1 和 rg2 的 PRIORITY 一样，但是 rg2 的 RU_PER_SEC 是 rg1 的两倍，那么 rg2 可使用的 CPU 时间是 rg1 的两倍。

🌟 参考材料

https://docs.pingcap.com/zh/tidb/stable/tiflash-pipeline-model#tiflash-pipeline-model- 执行模型

问题 5: 使用 TiProxy 后，读写性能会损失多少

TiProxy 适用于以下场景：

连接保持：当 TiDB 缩容、滚动升级、滚动重启操作时，客户端连接会断开，导致报错。如果客户端没有幂等的错误重试机制，则需要人工手动检查错误并修复，这大大增加了人力成本。TiProxy 能保持客户端连接，因此可以避免客户端报错。
频繁扩缩容：应用的负载可能周期性地变化，为了节省成本，你可以将 TiDB 部署到云上，并根据负载自动地扩缩容 TiDB server。然而，缩容可能导致客户端断连，而扩容不能及时地实现负载均衡。通过迁移连接功能，TiProxy 能保持客户端连接并实现负载均衡。

TiProxy 不适用于以下场景：

对性能敏感：TiProxy 的性能低于 HAProxy 等负载均衡器，因此使用 TiProxy 会降低 QPS。请参阅 TiProxy 性能测试报告。
对成本敏感：如果 TiDB 集群使用了硬件负载均衡、虚拟 IP 或 Kubernetes 自带的负载均衡器，此时增加 TiProxy 组件会增加成本。另外，如果在云上跨可用区部署 TiDB 集群，增加 TiProxy 组件也会增加跨可用区的流量费用。
TiDB server 的故障转移：只有当 TiDB server 在计划内的下线或重启操作时，TiProxy 才能保持连接。如果 TiDB server 意外下线，则连接仍然会断开。

当符合 TiProxy 的使用场景时，推荐使用 TiProxy。当对性能敏感时，推荐使用 HAProxy 或其他代理。

TiProxy 与 HAProxy 对比测试结果如下：

TiProxy 的 QPS 上限受工作负载类型的影响。在 Sysbench 的基本工作负载、同等 CPU 使用率的情况下，TiProxy 的 QPS 比 HAProxy 低约 25%
TiProxy 能承载的 TiDB server 实例数量根据工作负载类型而变化。在 Sysbench 的基本工作负载下，一台 TiProxy 能承载 5 至 12 台同机型的 TiDB server 实例
查询结果集的行数对 TiProxy 的 QPS 有显著影响，且影响程度与 HAProxy 相同
TiProxy 的性能随 vCPU 的数量接近线性增长，因此增加 vCPU 的数量可以有效提高 QPS 上限
长连接的数量、短连接的创建频率对 TiProxy 的 QPS 影响很小

🌟 参考材料

https://docs.pingcap.com/zh/tidb/stable/tiproxy-overview

https://docs.pingcap.com/zh/tidb/stable/tiproxy-performance-test

问题 6: 共享临时存储是将数据存储到哪里？

TiDB 采用计算存储分离架构，具有出色的扩展性和弹性的扩缩容能力。从 v7.1.0 开始，TiDB 引入了一个分布式执行框架，以进一步发挥分布式架构的资源优势。该框架的目标是对基于该框架的任务进行统一调度与分布式执行，并提供整体和单个任务两个维度的资源管理能力，更好地满足用户对于资源使用的预期。

目前，全局排序会使用大量 TiDB 节点的计算与内存资源。对于在线增加索引等同时有用户业务在运行的场景，建议为集群添加新的 TiDB 节点，为这些 TiDB 节点设置 tidb_service_scope，并连接到这些节点上创建任务。这样分布式框架就会将任务调度到这些节点上，将工作负载与其他 TiDB 节点隔离，以减少执行后端任务（如 ADD INDEX 和 IMPORT INTO）对用户业务的影响。

tidb_cloud_storage_uri 变量在 v7.4 引入用来指定全局排序中使用的 Amazon S3 云存储的 URI。在开启 TiDB 分布式执行框架后，你可以配置 URI 指向具有访问存储所需权限的云存储路径，以此来实现全局排序的功能。更多详情，参考 Amazon S3 的 URI 格式。
以下语句支持全局排序功能：
ADD INDEX 语句。
用于将数据导入本地部署的 TiDB 的 IMPORT INTO 语句。对于 TiDB Cloud，IMPORT INTO 语句不适用全局排序。

🌟 参考文档

https://docs.pingcap.com/zh/tidb/stable/tidb-distributed-execution-framework

https://docs.pingcap.com/zh/tidb/stable/tidb-global-sort

问题 7: 链路追踪计划是哪个版本可以使用？是 explain analyze 吗？

链路追踪计划在 TiDB 产品演进方向尤为重要。早在 TiDB v4 版本提供数据读写流量的可观测，TiDB Dashboard 是 TiDB 自 v4.0 版本起提供的图形化界面，可用于监控及诊断 TiDB 集群，可实现链路追踪，实现可观测性。其中分析集群读写流量分布及趋势变化，详细了解耗时较长的 SQL 语句的执行信息，诊断常见集群问题并生成报告。

TiDB v4.0 的集群日志表提供了一个全局且时间有序的日志搜索结果，为跟踪全链路事件提供了便利的手段，另外也提供 TRACE 可视化分析能力。TiDB 即将支持 opentelementry 的完整的链路追踪在计划中，未来版本会提供。当前可以利用 TRACE 命令，当前版本提供的 tidb_session_alias 变量，解决一些场景的问题，tidb_session_alias 和 connection_id 会标记到 session 相关的所有日志里，包括 tidb, tikv 和 tiflash。

TiDB v5 版本集群日志表 CLUSTER_LOG 表用于查询集群当前所有 TiDB/PD/TiKV 节点日志。它通过将查询条件下推到各个节点，降低了日志查询对集群的影响。该表的查询性能优于 grep 命令。例如按照某一个 region id 搜索日志，可以查询该 Region 生命周期内的所有日志；类似地，通过慢日志的 txn id 搜索全链路日志，可以查询该事务在各个节点扫描的 key 数量以及流量等信息。

TiDB v8.0.0 开始提供 TIDB_INDEX_USAGE 表，你可以使用该表查看当前 TiDB 节点中所有索引的访问统计信息。

🌟 参考材料

https://tidb.net/blog/758968d9

https://docs.pingcap.com/zh/tidb/stable/sql-statement-trace

https://docs.pingcap.com/zh/tidb/stable/information-schema-cluster-log

https://docs.pingcap.com/zh/tidb/stable/information-schema-tidb-index-usage

问题 8: 产品演进会有类似于 ti binlog 的功能吗，可以像 mysql 一样分析日志吗？

MySQL 分析日志场景可以考虑使用 general log ，其格式与 MySQL 兼容的功能，开启后能够记录数据库执行的所有 SQL 语句，为问题诊断提供依据。TiDB 在 v8.1 以后支持此功能，你可以通过设置变量 tidb_general_log开启该功能。在之前的版本中，general log 的内容只能和其他信息一起写入实例日志中，这对于需要长期保存日志的用户来说并不方便。从 v8.0.0 开始，你可以通过配置项 log.general-log-file 指定一个文件名，将 general log 单独写入该文件。和实例日志一样，general log 也遵循日志的轮询和保存策略。另外，为了减少历史日志文件所占用的磁盘空间，TiDB 在 v8.0.0 支持了原生的日志压缩选项。你可以将配置项 log.file.compression 设置为 gzip，使得轮询出的历史日志自动以 gzip 格式压缩。

原 TiDB Binlog 在 v8.1 之前支持，TiDB 提供的 TiCDC 工具在 v6.5 以后为主推工具，TiCDC 适用于以下场景：