地产TiDB使用初探索

地产TiDB使用初探索

业务介绍

  • 公司主要涉及地产开发、商业运营、智慧服务、长租公寓四大主航道业务,这次TiDB初探主要使用在智慧服务场景,智慧服务的服务业态涵盖了住宅、商业、公建及城市等的物业管理服务。

  • 跟业务介绍完TiDB特点后决定将物业能耗业务接入TiDB,主要考虑到TiDB比MySQL好的两个优势,分库分表和运维复杂度。

  • 业务数据不断增长,能耗信息保留周期较长,现数据使用分库分表方式存储

现状&目的

  • 现在业务数据存放于MySQL的分库分表中,分布为8个实例、320个分表,单表行数在4千万行。SQL单次执行在2s左右,在业务并发升高时响应超过10s,业务无法接受。
  • 数据保留周期还需更长,单表面临的数据量会更大,业务响应时间会更长,这将面临再次进行分库分表。业务有较多的OLAP类统计需求,二次分表和新增统计需求增加了逻辑复杂度。TiDB上不用在考虑分库分表,不用写更加复杂的逻辑。
  • TiDB可实现快速水平扩展,不用DBA进行复杂的数据搬迁,对业务可做到几乎无感知。

准备和测试

  1. 对现有问题梳理后结合现在TiDB特点我们想到可以试试TiDB,随即今年9月搭建4.0.6版本的TiDB功能和新能测试,用来与现有MySQL进行对比。

  2. 主要对查询统计类业务进行压测;

    • 环境:MySQL 8c32G 8个单节点,TiDB 8c32G的6节点集群,磁盘都为ssd。
    • 测试结果:相同接口响应时间MySQL比TiDB长2.5倍左右。 但发现在单SQL修改数据量大时MySQL会更快些,把大事务分成小事务并行修改效果不比MySQL差。

    下图是能耗统计接口的压测数据:

整个测试从9月初进行到了10月,测试服务预期,解决我们最主要的分库分表统计复杂的问题。TiDB统计类接口处理更快,随着并发增加更明显。

TiDB的使用

【使用架构】

  • 刚上线大半月先解决分库分表问题,使用DM拉去MySQL全量和增量数据到TiDB,DM对分库分表进行合并。

【使用现状】

  • 业务
    • TiDB作为多个MySQL的从节点,负责线上数据的聚合存储,应用数据统计分析服务。
  • 集群
    • 测试集群:4.0.6,前期的功能和新能测试。
    • 线上集群:4.0.8,90%的统计分析服务。
    • 4.x 集群一键部署方便快捷,提升自动化运维效率。
    • DM 2.0 同步MySQL数据到TiDB。
  • 数据同步
    • dm实时同步8个分片数据到TiDB集群。

【解决问题】

  • 提升了统计类接口响应时间。

【业务迁移】

  • 时间较短,现只将统计分析类服务迁移至TiDB,其他服务还在逐步迁移中。因为OLAP场景业务直接修改链接地址。

成效

统计分析业务响应时间提升了3倍左右,高并发情况下提升更高。

统计类新需求缩短一定的开发时间。

未来规划

我们刚开始初步探索TiDB使用,经过前期的测试、各方的沟通协调,这次初体验情况,我们看好 TiDB 的发展。

后续我们会推进更多的业务场景使用,TiDB成为DBA团队正式纳管数据库技术栈。

我们刚开始使用,部分功能还在逐步完善中,监控展示TiDB还是独立的一套,关键指标需要统一接入到监控平台便于查看。

现TiDB作为MySQL的从库还未对TiDB做备份策略,本月要完成TiDB定期备份。

2赞