TDSQL Boundless

TDSQL Boundless有什么功能？

一：透明分布式与 MySQL 高兼容

计算节点基于 MySQL 实现，兼容大多数 MySQL 原生语法与生态工具，使用时无需在业务侧指定分区键或手工分库分表。

支持单机 MySQL 应用无损迁移接入，实现对业务零入侵。

二：多节点高性能读写与弹性扩展

采用多主计算层设计，每个节点均可承载读写流量并支持弹性扩缩容。

三：低成本海量存储

存储层采用 LSM-Tree 与 SSTable，结合智能压缩策略，支持大规模数据存储能力。

在高重复度数据场景下相比传统引擎可实现显著的数据压缩，从而降低存储成本。

四：原生 Online DDL 与完整分布式事务保障

支持 MySQL 原生的 instant 类 DDL 及大多数在线 DDL 的无阻塞执行，减少变更对业务的影响。

分布式架构原生保障 ACID ，支持全局一致性读，存储节点承担事务协调职责，在扩缩容与切主等操作中保持事务不中断。

五：智能数据调度与云原生管控

支持数据位置感知与灵活调度，用于打散热点、优化查询路径与实现容灾策略。

管控采用容器化交付，支持快速部署与弹性扩缩容；提供集群版本与基础版本两种部署形态。

为什么选择TDSQL Boundless？

一：极致成本效益

• 超高存储压缩，削减成本

相比单机 MySQL，提供高达 20 倍的压缩率，大幅降低存储占用与成本。成本至多可降低至原来的 20%。

• 平滑迁移，降低改造成本

高度兼容 MySQL，透明分布式，业务平滑迁移无需修改代码。

• 资源消耗贴合业务成长

资源使用可随业务伸缩，轻松应对大促和用户激增而无需资源预留和闲置，实现成本与性能的精准平衡。

二：透明弹性又敏捷的架构

• 全托管数据库服务

在线变更服务器规格、滚动升级、自动备份，一键还原。全托管 TDSQL 服务让用户无需操心繁琐的运维。

• 平滑弹性扩缩容

支持从几十 TPS 到千万 TPS、GB 到 PB 级数据量的平滑弹性扩缩容且不影响在线业务运行。

• 在线表结构变更

支持在线表结构变更，支持敏态业务快速迭代上线。

三：金融级高可用

• 内建容灾设计

系统内置完善的容灾机制，确保高可用性与业务连续性。

• 自动秒级故障切换

无论是小规模几节点还是大规模集群，节点异常时故障切换自动完成，用户无需干预，恢复时间可达秒级。

• 跨中心与跨地域容灾

支持跨中心乃至跨地域的容灾部署，真正保障数据安全，防止数据丢失。

TDSQL Boundless 在读取场景中是否存在性能问题？如何确定数据分片的位置？

在 TDSQL Boundless 分布式数据库中，读取性能可能会受到数据分片和查询方式的影响。以下是两种常见的情况：

带分区键的查询：如果查询中包含了分区键，TDSQL Boundless 能够直接将查询路由到包含该分区键的具体数据分片上。这种方式非常高效，因为它避免了不必要的数据遍历，直接定位到了正确的数据节点。

不带分区键的查询：当查询没有指定分区键时，TDSQL Boundless 需要通过二级索引来确定数据的位置。这种情况下，系统会在包含该表数据的节点上进行遍历查询，这可能会导致性能上的轻微下降，因为需要检查更多的数据。

TDSQL Boundless 的 Compaction 对性能有何影响？

TDSQL Boundless 中的 Compaction 过程主要包括两个动作：读取上一层文件，进行 sort-merge 操作，然后将结果写入下一层或下几层的文件。这个过程主要消耗 CPU 和 I/O 资源。因此，只要系统有足够的资源，Compaction 本身通常不会对业务性能产生明显的影响，甚至可能没有影响。

此外，由于 TDSQL Boundless 采用天然的分布式架构，它可以利用所有节点的资源来进行 Compaction，这与传统的主从架构不同，在主从架构中，通常只有主库的资源被用于处理读写操作（不考虑读写分离的情况）。因此，TDSQL Boundless 的分布式特性有效地弥补了可能需要为 Compaction 准备额外资源的问题。

关于 Compaction 对性能影响的担心，很大程度上是因为早期 RocksDB 实现中相对简单的 Compaction 策略，这留下了一些关于 Compaction 影响的 "传说"。然而，随着版本的不断迭代，Compaction 策略已经进行了大量的优化，使得对性能的影响更加可控。

InnoDB 与 TDSQL Boundless 在大事务主备延迟问题上是否有相同的表现？

InnoDB 和 TDSQL Boundless 在处理大事务主备延迟问题上表现出不同的特性：

InnoDB：InnoDB 使用二进制日志（binlog）来同步主备数据。在高并发和大数据量的场景下，大事务可能会导致主备之间的延迟，因为 binlog 的复制和重放过程可能会很耗时。

TDSQL Boundless：TDSQL Boundless 是一个基于 Raft 协议的分布式数据库，它通过 Raft 日志实时同步节点间的数据。在 Raft 协议中，Leader 节点会在接收到客户端请求后，先将请求作为一个新的日志条目添加到本地日志，然后复制到 Follower 节点。只有当日志条目被复制到多数派节点并被标记为可提交状态后，Leader 节点才会响应客户端。这种设计有效减少了大事务可能导致的延迟。

在 TDSQL Boundless 中，主备节点之间的 apply 操作几乎不会有延迟。唯一的潜在延迟是 Follower 节点需要等待 Leader 节点发送下一个日志条目（或心跳）来获取可以提交的索引。然而，这个时间间隔通常非常短，可以忽略不计。

此外，TDSQL Boundless 对事务的大小有限制，尤其是对于删除操作，建议将大事务拆分成多个小事务执行。这有助于避免单个事务占用过多资源，减少对系统性能的影响。

综上所述，与 InnoDB 相比，TDSQL Boundless 的 Raft 协议同步机制在大事务处理上提供了更低的主备延迟，特别是在高并发和大数据量的场景下。

基于 LSM-tree 的 TDSQL Boundless 查询性能是否低于原生 MySQL？

与 MySQL 的 B+ 树索引相比，LSM-tree（Log-Structured Merge-tree）在写入性能上有显著优势，但在读取性能上可能会有所牺牲。

然而，TDSQL Boundless 作为一款分布式数据库，提供了多种机制来提升查询性能：

1. 垂直/水平扩容：TDStore 可以通过增加更多的节点来扩展数据库的处理能力，从而提高每秒查询率（QPS）。这是单机 MySQL 无法实现的，因为单机 MySQL 的性能受限于单个服务器的硬件资源。

2. 优化策略：即使在单节点上，TDSQL Boundless 也采用了一系列优化策略来提高读取性能：

Leveling Compaction：TDSQL Boundless 将所有数据（包括主键和索引）存储在一个大的、有序的键值对空间中，这些数据在物理磁盘上对应多个 SST 文件，分为 L0 到 L6 共七层。Leveling Compaction 策略确保了除了 L0 层之外的每一层中键的唯一性，这有助于加快查询速度。L0层较为特殊，允许文件间存在范围重叠，但 TDSQL Boundless 会限制 L0 层的文件数量，通常不超过四个。当需要访问数据时，TDSQL Boundless 首先检查内存 memtable，如果数据不在 memtable 中，则按层次顺序检查磁盘上的 SST 文件。由于 L1 到 L6 层的键是唯一的，因此每层只需检查一个 SST 文件即可确定目标数据是否存在。

Bloom Filter：在查找数据时，TDSQL Boundless 使用布隆过滤器来快速排除那些不可能包含目标键的 SST 文件，这样可以避免不必要的磁盘查找，节省资源。

Block Cache：TDSQL Boundless 利用块缓存来存储热点数据，减少对磁盘的 I/O 操作，进一步提高读取性能。

综上所述，尽管基于 LSM-tree 的 TDSQL Boundless 在读取性能上可能不如优化过的 MySQL 实例，但通过分布式架构和一系列优化措施，TDSQL Boundless 仍然能够提供高效的读写性能，特别是在大规模数据处理和高并发访问的场景中。

TDSQL Boundless 引擎与原生 MySQL 在读写性能上有何差异？

TDSQL Boundless 是一款原生分布式数据库。它通过 Raft 协议在数据单元的副本之间保持一致性，默认情况下每个数据单元有三个副本，并且这些数据均匀分布在所有数据节点上。这种数据分布策略极大地提升了处理大量写入操作的效率，尤其在写多读少的业务场景中表现出色。

与 MySQL 的 InnoDB 存储引擎相比，TDSQL Boundless 能够实现3~9倍的数据压缩率，这不仅有效减少了存储空间的需求，还可能提高 I/O 性能。因此，TDSQL Boundless 特别适合那些对写入性能有较高要求的场景。

在 TDSQL Boundless 中，是否需要使用分区表？

在单机版中，分区表主要用于通过分区裁剪提升 SQL 性能和通过drop partition的方式定期清理数据。而在 TDSQL Boundless 分布式场景下，使用分区表的好处还包括利用多个节点的写入能力，这对于大数据量的处理尤为重要。

当面临大规模数据迁移时，建议预先将大表改造成基于 Hash 的分区表。这样做可以利用 TDSQL Boundless 多节点的能力来加速数据导入过程。

如果没有预先分区，而是创建了一个单表，那么在数据导入初期，所有的写入操作都会集中在一个数据节点上，这可能导致 I/O 瓶颈。TDSQL Boundless 提供了自动分裂和数据迁移的功能，但如果表一开始没有分区，这个过程可能会比较缓慢，并且在分裂和迁移期间，副本均衡也会带来额外的 I/O 开销。

通过创建分区表，可以最大限度地发挥 TDSQL Boundless 分布式数据库的能力。这种改造的成本很低，只需要修改建表语句，而不需要对业务代码进行任何其他适配。例如，如果您的 TDSQL Boundless 实例包含30个节点，创建一个包含30个分区的一级 Hash 分区表，TDSQL Boundless 会在每个节点上创建一个主副本，从而实现副本均衡。同时，业务的增量数据会均匀分布在所有节点上，每个节点的压力也会相对均衡。

总之，为了充分利用 TDSQL Boundless 的分布式特性并避免潜在的性能瓶颈，创建分区表是一种推荐的最佳实践。

TDSQL Boundless 目前的灾备能力支持情况如何？

TDSQL Boundless 具备多样化的服务高可用技术，包括实例内的多副本容灾和实例间的物理备库容灾。

实例内的多副本容灾

同机房三副本：同机房内三副本组成一个实例，能够防范少数派节点故障，无法防范机房级故障。

同城三机房三副本：面向具备一个城市三个机房的场景。同城三个机房组成一个实例（每个机房是一个可用区），机房间网络延迟一般在0.5 ~ 2ms之间。能够防范少数派节点故障、单机房故障，无法防范城市级故障。

实例间的物理备库容灾：当前已具备同城灾备和跨城灾备能力。在两个完全独立的实例之间提供数据同步以及切换主备关系的能力。当主库出现计划内、外的不可用情况时，备库可以接管服务。

TDSQL Boundless有什么应用场景？

一：海量关键数据管理

• TDSQL Boundless 支撑在线关键业务的高并发读写与低延时需求，保障业务可用性。
• 运维与扩容更便捷，存储高性价比，应对海量数据管理变得轻而易举。
• 能够稳定承载销售订单、用户账号、充值记录与交易流水等核心数据存储。

二：架构现代化

• 用 TDSQL Boundless 直接替换分库分表的 MySQL 和 HBase，摆脱陈旧技术栈带来的复杂性。
• 简化开发与交付流程，使业务开发效率明显提升。
• 降低维护成本并提升系统可靠性，运维更轻松、故障处理更可控。

四：统一视图

• 使用 TDSQL Boundless 轻松汇聚不同业务线的数据，构建统一的数据入口。
• 消除数据孤岛，实现跨业务的数据联通与共享。
• 放大数据价值，提升跨部门协同与决策效率。

五：实时分析

• TDSQL Boundless 能结合海量弹性存储与分布式计算能力，满足大规模在线分析需求。
• 实时同步业务变更，确保分析结果与业务状态保持同步。
• 支撑即时洞察与快速响应，助力业务监控与优化。

六：低成本温冷数据归档

• TDSQL Boundless 通过超高压缩率显著降低归档存储成本。
• 归档数据仍可支持高并发的在线检索，满足查询需求。
• 既能长期低成本保存历史数据，又能按需高效访问。