诺亚体育棋牌优惠:TiDB在360的落地及实战干货

背景

?

Part1:写在最前

当一张百亿数据量的表放在你面前,你将面临着什么?

加列?哭吧,怎么也得等个几天甚至几周。加索引?哭吧,不论你用pt-online-schema,还是gh-ost,你都面临着拷贝一张临时表用以存储临时数据,磁盘已经80%了,你这一张表就占几百G,你咋弄?~

我先说几个最让你兴奋和开心的点吧:

  1. 在TiDB里,你完全不用担心磁盘容量的问题;

  2. 在TiDB里,原生支持Online DDL,你完全不用担心第三方改表工具改表出现各种Bug的问题,相信用开源工具改过上T级别表的同学都遇到过或多或少的各类error。

  3. 在TiDB里,加列,主键扩容字段都是秒级的,比如我刚刚就刚对一张19亿的表加完了字段,1s完事儿~这在MySQL里要8.0才可以,而且还要求列在最后才行。

  4. 在TiDB里,你会发现count(*)惊人的快,一张近20亿的表coun(*)大概在1分钟完事儿,当然,这取决于你的KV数量和磁盘性能。

  5. 在TiDB里,从MySQL迁移将变得简单,图形化一键迁移,爽不爽?

  6. 在TiDB里,绝大多数情况你会发现比单机MySQL有更好的性能,当然也不排除一些例外,例如enum这样奇葩的字段类型。

  7. 在TiDB里,......,您且往下看,我慢慢和您说~

?

Part2:使用背景

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 版本我们是直接选取的最新版,后一路跟随新版本升级。

?

Part3:集群架构