【转】TiDB 在 Mobikok 广告系统中的应用和实践

小白龙

场景介绍：SSP系统
订阅 SSP（Sell-Side-Platform）平台当前业务主要分为：SDK、Smartlink、Online API 以及Offline API；在当前 SSP SDK 业务系统当中，累计用户已达到 2 亿，最初使用的是 MySQL 主从分表的方式存储用户数据，随着数据量的增加，MySQL 单机容量以及大数据量查询成为了瓶颈；当单表数据达到 2 千万以上时，单机 MySQL 的查询以及插入已经不能满足业务的需求，当访问量到一定阶段后，系统响应能力在数据库这一块是一个瓶颈。
一次很偶然的机会在 GitHub 上面了解到 TiDB，并且因为现在业务系统当中使用的 Redis 集群是 Codis，已在线上稳定使用两年，听闻 TiDB 创始团队就是之前 Codis 的作者，所以对 TiDB 有了极大的兴趣并且进行测试。通过测试单机 MySQL 和 TiDB 集群，当数据量达到数千万级别的时候发现 TiDB 效率明显高于 MySQL。所以就决定进行 MySQL 到 TiDB 迁移。
迁移后整体架构图：


引入TIDB
在选择使用替换 MySQL 方案当中。我们主要考虑几点：

• 支持 MySQL 便捷稳定的迁移，不影响线上业务；
• 高度兼容 MySQL，少改动代码；
• 支持水平弹性部署服务以及在线升级；
• 支持水平扩展业务；
• 成熟的配套监控服务。
  

TiDB 数据库整体集群配置：2* TiDB、3* TiKV、3* PD。


从 12 月初正式上线到目前为止，TiDB 稳定运行四个多月，最高 QPS 达到 2000，平均 QPS 稳定在 500 左右。TiDB 在性能、可用性、稳定性上完全超出了我们的预期，但是由于前期我们对 TiDB 的了解还不深，在此迁移期间碰到的一些兼容性的问题，比如 TiDB 的自增 ID 的机制，排序的时候需要使用字段名等，咨询 TiDB 的工程师都很快的得到了解决，非常感谢 TiDB 团队的支持以及快速响应。
下图是当前集群的 Grafana 展示图：

后续计划
使用 TiDB 对于像我们这样可预期核心数据会暴增的场景，有非常大的意义。在后端支撑力量有限时，业务暴增时只需要增加机器，而不是频繁重构业务，让我们有更多精力在自己的业务上耕耘，增加我们的行业竞争力。未来我们还有 ADX（Ad Exchang，广告交易平台） 和 DSP 业务，需要处理海量的用户数据以及广告数据。目前统计数据这一块当前业务当中使用的是 Spark Streaming，通过和 TiDB 开发团队沟通，官方 TiSpark 可直接引入到当前统计 Spark 群集当中，非常期望在后续开发当中使用 TiSpark。
问题建议
在实际应用当中，因为我们切换的并不是只有用户数据表，还迁移了关于广告业务、渠道业务基础数据表。由于 TiDB 是一个分布式数据库，对于一些小表以及 count(*) 操作会影响效率，后来咨询 TiDB 官方得知，TiDB 有不同的隔离级别，SQL 也有高低优先级，如果有全表扫描的需求，可以使用低的隔离级别或者是低的优先级。将来我们就可以直接所有线上业务使用 TiDB 进行替换，最后还是非常感谢 TiDB 团队的支持与帮助。

作者：rayi，深圳可可网络服务端架构负责人

作者：PingCAP
链接：https://juejin.im/post/5ad805386fb9a045fa6c8120
来源：掘金
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

河小马

小白龙 发表于 2019-6-18 15:45
为什么用独立服务器，而不是用云服务器呢？

配置上去了，独立服务器要便宜很多，而且资源没有限制

就像AWS 一样，资源都是有限制的，尤其是SSD

小白龙

为什么用独立服务器，而不是用云服务器呢？