DRDS 与 TiDB 浅析

在谈论数据库架构和数据库优化的时候，会常听到“分库分表”、“分片”、“Sharding”…等关键词。值的高兴的是，这部分公司的业务量应该正在实现（或者即将面临）高速增长，或技术方面也面临着一些挑战。但让人担忧的部分是，他们的系统“分库分表”真的有选择正确吗？

随着业务规模的不断扩大，用户需要选择合适的方案去应对数据规模的增长，以应对逐渐增长的访问压力和数据量。关于数据库的扩展主要包括：业务拆分、主从复制、数据库分库与分表等，本篇文章的灵感就来源自作者与朋友关于数据库分库分表问题的讨论。

DRDS vs TiDB

起源

DRDS

• 数据库中间件 Cobar、MyCat、Amoeba

Tidb

• Google Spanner/F1

架构

DRDS 架构

TiDB 架构

分片机制

DRDS

• 支持 HASH、RANGE_HASH、MMDD 等多种分片类型

• 原理上都是基于 HASH 分片

• 需要在建表时指点分片 Key 以及分片方式

• 不支持全局唯一索引

TiDb

• 通过 multi-raft 协议，将数据 Region（按范围分区）分布于不同节点，分片不需要应用干预

• 由于按照范围对数据进行分片，在某些范围数据被集中访问时易造成热点问题，业务上可以通过对主键进行散列编码打散数据或者热点数据通过 cache 方式解决该问题

应用限制

DRDS

• Sharding 后对应用和 SQL 的侵入都很大，需要 SQL 足够简单，这种简单的应用导致 DB 弱化为存储。

• SQL 不能跨维度 join、聚合、子查询等。

• 每个分片只能实现 Local index，不能实现诸如唯一键、外键等全局约束。

TiDB

• 不支持外键

• 自增主键保证唯一但不保证连续

支持的事务模型

DRDS

• DRDS 本质上是 DB Proxy，事务基本上是指 Proxy 层的事务，原则上并不涉及 RDS 数据库级别的事务

• FREE:允许多写;不保证原子性;无性能损耗;数据批量导入、表初始化等场景

• 2PC:两阶段提交事务;保证原子性，不保证可见性;推荐 MySQL 5.6 用户使用

• XA:XA 强一致事务;保证原子性;保证可见性;推荐 MySQL 5.7 及更高版本用户使用

• FLEXIBLE:柔性事务;补偿型事务;适用于性能要求较高、高并发的业务场景

TiDB

• TiDB 参考 Percolator 事务模型，事务下沉到 TiKV（存储引擎）

• 通过 2PC(Prewrite 阶段和 Commit 阶段)提交以及乐观锁保证分布系统中的 ACID

• TiDB 提供的事务隔离级别（Snapshot Isolation）与 MySQL 提供的事务隔离级别保持一致

高可用保障

DRDS

• 通过下游 RDS 主备方案保证数据高可用

• 数据冗余两副本以上，基本上从节点不参与计算只进行数据备份，资源上比较浪费

• 跨机房多地部署实施困难，需要借助同步工具或业务上实现数据双写

TiDB

• tidb 的元数据存储在 pd 中，通过 pd 调度数据分片

• 分片最低三副本，通过 multi-raft 调度

• 通过节点标签影响 pd 调度，实现两地三中心部署

从架构来讲 TiDB 的原生三副本机制要优于 DRDS 通过异步数据同步实现高可用的机制。异步同步主要的缺点是切换周期长，存在数据丢失的风险。对于 DRDS 当业务系统使用 XA 或者 GTS 这种强一致性协议时，某节点宕机会导致服务整体不可用

扩缩容再平衡机制

横向扩索容主要考虑数据再平衡的效率和对在线业务系统的影响问题。考虑到 DRDS 分库分表采用哈希切分，那么在数据再平衡时需要针对分片 key 将所有数据进行重新分片，造成网络及系统开销较大；TiDB 采用 Range 分片机制，当节点数发生变化，根据 pd 调度，只对部分 Region 进行迁移，系统开销理论上小的多.

运维成本

DRDS

• 由于 DRDS 多由云厂商开发，本质上是一种服务，不存在运维成本，只有沟通成本

• 由于 Proxy 层技术不透明，数据又基于 RDS，系统性能优化需要与厂商沟通解决

TiDB

• 社区提供了 ansible 为基础的安装运维包，可以说单纯运维门槛不高，基于 prometheus 和 grafana 提供比较完善的监控系统

• 性能优化一部分靠生态提供的工具，pd-ctl、tidb-ctl 等。另一方面靠社区的相应

• 源码透明，可以深入了解其实现

应用场景

DRDS

• 顺时高峰且易形成数据热点的场景

• DRDS 的分片机制为 hash 分片，天然将数据打散到各个节点，借助 RDS 本身的缓存机制可以很好的缓解数据热点。比如企业的考勤系统或银行的柜员系统，在早上上班高峰并发量多，几分钟到一个小时的时间内员工会集中打卡或者登录单例数据库会瞬间达到性能瓶颈。

TiDB

• 多租户 SaaS 应用：

该场景多为多租户场景，SAAS 供应商为每一个用户提供单独的库，每个数据库的数据量不均衡。如果使用 MySQL 单实例挂载多库的方式只能纵向扩展；多实例多库方式要么在应用层为每个应用程序配置不同的数据库 URL，要么实现业务数据 Router；采用 TiDB 可以统一管理数据资源，将多个实例转化为一个集群维护，同时借助 TiDB 的数据分片机制避免单一用户形成实例热点。

• 微服务架构统一管理数据资源：

微服务架构的一个原则是数据可拆分，但如果每个微服务使用 MySQL 主备方式维护一组 MySQL 实例不仅不便于管理，而且由于每个服务对数据库资源使用的不均衡及易造成资源浪费。应用 TiDB 集群不仅可以很好的解决上述问题，而且便于维护，同时就业务来讲比较容易形成数据服务中间层。

备份机制

DRDS

依赖于 RDS 本身的备份机制

TiDB

• Tidb 遵循 MySQL 协议，全量情况下可以通过 MyDumper 等逻辑备份工具备份数据

• 增量数据可以通过社区提供的 TiDB-Binlog 实时生成增量备份文件

应用改造成本

DRDS

• 分片键的选择，实际开发中通常会存在说干业务依赖于同一张表的情况，通过某一个列作为分片条件提高某项业务性能时可能隐性降低某些业务的性能。

• 分片算法的选，DRDS 的拆分算法很多，择简单取模、数值向右移、双拆分列哈希等等，需要开发者先弄清楚这些概念再根据业务情况进行选择

• 拆分后的表不支持全局唯一约束，如果由于业务需求必须维护全局唯一只能通过建立中间表的方式维护唯一性，增加开发成本和数据库调用次数

• 拆分后的表部分 SQL 要根据 DRDS 的扩展语法重写

TiDB

• TiDB 的 SQL 实质上是 MySQL 语法的一个完全子集，如果业务没有用到 MySQL 的内建函数和外键约束的话基本可以平滑迁移，只需要对部分 SQL 根据 TiDB 架构特性进行优化

• 如果重度应用 MySQL 的系统存在某些 TiDB 不支持的函数，那么这部分功能需要应用端实现

总体上来讲，DRDS 的应用改造成本主要集中在业务数据拆分上，以及由于数据拆分带来的业务应用重构；Tidb 由于自身架构原生支持分片所以不存在数据拆分问题，应用重用主要由于对 MySQL 的私有内建函数依赖重。

个人观点总结

DRDS 起源于 DB 中间件，通过 hash 算法做数据分片用于扩展单机数据库的不足，属于过度产品，扩展时数据再平衡的时间会随着数据及节点数量的增加而增加。从应用改造后续维护的角度来讲，性价比不高。从场景上来讲 DRDS 的 hash 分片机制可以更好的散列数据，更加不易形成数据热点；TiDB 在频发访问的数据量小于 64M 时易形成热点，当数据的范围大于 64M 的时候几乎可以数据会被分配到其他节点热点也随之消除。

从应用架构来考虑，这个量级的热数据完全可以通过缓存解决。TiDB 从架构来讲是一个很优雅的数据库系统，社区及公司历史不长但发展很快，在实际使用过程中会遇到一些坑，这些坑一部分是由于产品成长过程中的 bug 或者待优化 feature 造成，另一部分是由于单机环境和分布式环境的差异造成的。勇于尝试新事物，也许未来收益会更大。