数据库架构演进
集中式架构（单机数据库）
性能与可靠性依赖特定硬件：扩展性差，存在单点故障风险。
弹性极差：当数据量从 GB 级增长至 TB 级（如几十 TB）时，单机硬件无法承载。
分布式数据库中间件架构（TDSQL MySQL（InnoDB））
优势：使用廉价硬件，降低了系统成本。
痛点：
中间件本身复杂：需要大量人力进行维护。
对业务侵入性强：建表时必须显式指定分片键；扩容时需要预先定义和执行复杂的拆表方案。
功能受限：跨库查询、分布式事务实现复杂，影响研发效率
原生分布式（TDSQL Boundless ）
原生 SQL 引擎：业务无需像使用中间件那样指定分片键或修改业务逻辑，对业务完全透明，如同使用单机数据库一样简单。
弹性伸缩架构：基于 TDStore 存储引擎的先进分片管理机制，实现类似 Manner 架构的智能化数据分布，使业务能够无感知地进行扩缩容。
降低综合成本：基于 LSM-Tree 存储结构构建，并且在每一层的数据都提供压缩算法，进一步压缩业务数据，从而降低综合成本。
TDSQL Boundless 总体架构
TDSQL Boundless 一体化存算分离的架构实现，很好地解决了 TDSQL MySQL（ InnoDB 引擎）在语法兼容性、弹性扩缩容能力上的短板。
计算引擎 ：访问远端的分布式 KV 存储，每条记录由计算层编码为
<Key, Value>；计算层的访问空间为 [0, +∞) 的线性 key 空间。存储引擎 ：分布式 KV 存储集群，作为事务协调者提供 Get/Put 接口；数据分片以 Key-Range 范围切分，由调度引擎控制分片粒度以及存放位置。
调度引擎 ：承接计算引擎和存储引擎的枢纽，维护和更新全局路由信息，调度和管理数据分片生命周期，实现业务无感知扩缩容。
DDL 操作流程（以建表为例）：
1. 业务发送 CREATE TABLE 语句 → 计算引擎
2. 计算引擎解析 DDL → 生成 DDL 任务
3. MC 接收 DDL 任务 → 与 TDStore 交互
4. 创建对应数据分片 → 更新路由信息
5. 返回执行结果 → 业务端
DML 操作流程（以数据插入为例）
1. INSERT 语句 → 计算引擎
2. 数据编码为 KV 格式 → Key: "table:pk", Value: "row_data"
3. 查询 MC 获取路由 → 确定目标分片位置
4. 通过 Put 接口 → 写入对应数据分片
5. 二级索引同步 → 写入索引分片
MC（调度引擎）的核心作用是为数据访问提供路由信息，并智能管理数据分片（Region）。当集群需要扩容加入新节点时，MC 会自动、平滑地将部分数据迁移到新节点上，使所有存储节点的负载趋于均衡。整个过程对业务应用完全透明，无需人工干预，实现了真正的“无感知”扩缩容。
TDSQL Boundless 元数据模型
面对分布式架构三大挑战：感知缺失、调度受限、规则固化，TDSQL Boundless 通过三级元数据模型破局。
DataObject ：表、索引、自增值等逻辑层面的概念抽象，定义了不同类型的数据结构，用于拓扑感知数据亲和性关系。例如，在创建一张表时，调度引擎会记录其表结构及二级索引等元数据。当后续进行数据分片（Region）的创建与调度时，系统会利用这些信息，尽可能将关联紧密的数据（如一张表的主键数据与其二级索引）放置在同一个物理节点上。这种机制旨在最大程度地减少跨节点访问和分布式事务，从而显著降低 SQL 查询的延迟与网络开销。
Replication Group ：基于 Raft 协议，物理层面存储 KV 的数据分片单元。一主 N 备，并保证数据一致性，具备多种不同角色，区分为 Leader、Follower、Learner、Witness，共同构成一个可靠的数据副本集合。
Region ：一段连续范围的 Key Range，是数据物理存储的最小单元。一个 RG 可以包含多个 Region。每个 Region 承载着某个 DataObject（例如一张表）的一部分实际数据。调度引擎的核心工作之一，就是根据 DataObject 定义的亲和性规则，将这些细粒度的 Region 智能地调度到合适的 RG 中进行存放与管理，从而实现性能与可用性的最优平衡。
