干货 | DRDS 与TiDB浅析

干货 | DRDS 与TiDB浅析

北京it爷们儿 京东云开发者社区  4月17日

在谈论数据库架构和数据库优化的时候，会常听到“分库分表”、“分片”、“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形成，另外一部分是因为单机环境和分布式环境的差别形成的。敢于尝试新事物，也许将来收益会更大。

[文章转载自公众号

  北京IT爷们儿]( mp.weixin.qq.com/s?__biz=MzU…)

阅读原文