为什么我们要从MySQL迁移到TiDB？ _MySQL

文章插图

当一张百亿数据量的表放在你面前，你将面临着什么？加列？哭吧，怎么也得等个几天甚至几周。加索引？哭吧，不论你用 pt-online-schema ，还是 gh-ost ，你都面临着拷贝一张临时表用以存储临时数据，磁盘已经 80% 了，这一张表就占几百 G ，你咋弄？
我先说几个最让你兴奋和开心的点吧：

在 TiDB 里，你完全不用担心磁盘容量的问题。
在 TiDB 里，原生支持 Online DDL ，你完全不用担心第三方改表工具改表出现各种 Bug 的问题，相信用开源工具改过上 T 级别表的同学都遇到过或多或少的各类 error 。
在 TiDB 里，加列，主键扩容字段都是秒级的，比如我刚刚就刚对一张 19 亿的表加完了字段， 1 秒完事，这在 MySQL 里要 8.0 才可以，而且还要求列在最后才行。
在 TiDB 里，你会发现 count(*) 惊人的快，一张近 20 亿的表 coun(*) 大概在 1 分钟完事儿，当然，这取决于你的 KV 数量和磁盘性能。
在 TiDB 里，从 MySQL 迁移将变得简单，图形化一键迁移，爽不爽？
在 TiDB 里，绝大多数情况你会发现比单机 MySQL 有更好的性能，当然也不排除一些例外，例如 enum 这样奇葩的字段类型。
在 TiDB 里， ...... ，您且往下看，我慢慢和您说。

使用背景360 云平台对 360 集团各大业务线均有提供服务支持，涉及的数据库支持方案有：MySQL、redis、MongoDB、ES、GP、PiKA 。
其中 MySQL 至今已有过万的实例，目前，对于一些写入量大的业务，已经出现瓶颈。
例如磁盘空间，虽然我们可以通过分库分表的方式，拆分出来，但这对业务和 DBA 来说都是不小的工作量，最痛苦的无异于这些大表的改表。
无论是单表上 T ，还是分库分表，对一张大表执行 DDL 的代价是非常大的。
针对业务爆发式增长的数据量，我们开始调研选型是否有其他数据库可以代替传统的 MySQL 。
通过调研我们了解到 TiDB ，迁移平滑，基本上无需业务变动代码，完全的事务 ACID 支持，分布式的架构，自带高可用、Online DDL 。
截止目前， 360 云平台这边有三套 TiDB 集群，总节点数在 50+ 。有 9 个业务线接入使用，有过百亿级表 Online 加索引的案例，总数据量目前在 80T 。
版本上，我们从 3.0.1 一路跟随到 3.0.5 ， DM 版本从内测到 1.0.2 GA 版本，共计提出 9 个 Bug 或改进项反馈。
后续我们计划将 TiDB 上到 360 HULK 云平台上，并定制化开发一些功能为业务提供可视化的服务，以便让 360 集团更多的业务线接触到 TiDB、使用 TiDB 。
版本的选择我们之所以从大版本 3 开始，也是看到了一些 2.X 版本的社区反馈，尤其是索引执行计划这块， 3.X 版本较之前的版本会好很多。DM 版本我们是直接选取的最新版，后一路跟随新版本升级。
集群架构

文章插图

整体架构上，我们除了 TiDB 集群外，还用到了 DM 和 Pump、Drainer 套件。
这块主要是由于我们使用 TiDB 的业务有两种：
①老的 MySQL 业务，因单机磁盘受限，导致单实例磁盘无法支撑爆炸式增长的数据量，数据比较重要，需要备份和支持 7*24 小时的恢复。
这类业务我们用到 DM 套件来实现无障碍迁移， 1TB 的导入时间在 16 小时，这里如果是比较大的数据源，且 TiDB 是全新集群，可以使用 TiDB-Lightning ，速度可以更快。
Lightning 的实测导入速度， 37 分钟，导完 2 张大表共计 54G 的数据，符合 100G/H 预估，是 loader 的 3 倍速度， loader 用时 2 小时 4 分钟。
说起 DM 使用这块文章后面会单独分享下这块需要注意的问题，如下图所示：