中移物联网在车联网场景的 TiDB 探索和实现( 二 ) 作者介绍：薛超

使用 MyCat 一段时间后，我们也在思考，目前的集群如果要做节点的扩容，成本高不高？风险大不大？结论是我们要花 4 到 5 天的时间来做节点扩容后的数据迁移，显然这个成本是相当昂贵的。这个时候，我们关注到了 TiDB ，官方介绍这个产品支持弹性的水平扩展，能够轻松的应对高并发，海量数据场景，支持分布式事务，并且有自动的灾难恢复和故障转移功能，听上去非常的诱人，我就找研发大佬聊了这个事情，我们一拍即合，后面的事情进展很顺利，资源申请、部署环境，我们很快的把 3 个 TiDB server、3 个 TiKV 和 3 个 PD 集群布置好，开始了一系列的场景验证。
遇到的问题第一个问题是在验证设备管理模块的时候，发现整个集群每一个节点的负载其实并不高，但是处理的效率比较低，导致队列有积压。为了解决这个问题，我们也咨询了官方的同事，进行了一些优化，比如调整批量的更新来减少开销，扩容一个 TiDB 的 server 节点，最重要的是把 TiDB 版本从 2.04 升级到 3.05 。
另外一个问题就是热点数据，因为 MySQL 的模型组件用的是自增的 int 类型，迁移过来以后热点数据效应比较明显。为了解决这一问题，我们将主键改成 uuid ，通过 shard_row_id_bits=N 这样的语句，来将数据打散，打散后数据写入的效率大大提升。听说现在 4.0 GA 版本的 AutoRandom 可以解决同样的问题，不再需要使用 uuid 作为组件，我们可以期待一下这个版本的新特性。
TiDB 解决了哪些痛点问题第一，它的水平扩展特性解决了 MyCat 等中间件分库分表带来的维护成本高的问题。通过无缝扩展 TiDB 和 TiKV 实力，提高系统的计算能力和存储能力。
第二， TiDB 兼容现有的 MySQL 的语法和协议，迁移成本低。我们从 MyCat 集群迁移到 TiDB 业务代码都非常少。在数据迁移方面，历史数据通过开发的迁移小工具，从 MyCat 集群读取出来，然后写到 TiDB 集群，数据是在代码层做的双写，我们很顺利的将数据迁移到了 TiDB 。
第三，海量数据下，查询效率非常优秀。我们的轨迹数据是按照日期分区的，每天会写入 4 亿到 5 亿的数据，那么在这个量级的数据场景下，我们设备 ID 的查询一般在 10 毫秒就能够返回结果，能够满足我们业务场景的需求。
第四，扩容和升级非常快捷。 TiDB 在版本升级方面真的非常好用，把准备工作做好之后， 3、4 分钟不到就完成了整个升级，用户体验非常棒。
TiDB 在物联网的应用前景我们公司的核心产品是物联卡，目前卡片数量在 7 亿以上；另外一个产品是智能组网，现在有将近 1600 万的家庭网关；在智能家居和智能娱乐方面，我们有 700 万左右的摄像头和智能穿戴设备，这几个场景都是属于高并发以及海量数据的场景，我认为这些场景都是比较适合迁移到 TiDB 上面跑的。随着我们车联网场景在 TiDB 上的使用越来越成熟，未来我们会推动更多的业务，迁移到 TiDB 上面。同时，也希望 PingCAP 公司的同学们，能够给我们带来更优秀的产品。