地产 TiDB 使用初探索
作者: huran_tidb 原文来源:https://tidb.net/blog/85fa5696
地产 TiDB 使用初探索
业务介绍
公司主要涉及地产开发、商业运营、智慧服务、长租公寓四大主航道业务,这次 TiDB 初探主要使用在智慧服务场景,智慧服务的服务业态涵盖了住宅、商业、公建及城市等的物业管理服务。
跟业务介绍完 TiDB 特点后决定将物业能耗业务接入 TiDB,主要考虑到 TiDB 比 MySQL 好的两个优势,分库分表和运维复杂度。
业务数据不断增长,能耗信息保留周期较长,现数据使用分库分表方式存储
现状 & 目的
现在业务数据存放于 MySQL 的分库分表中,分布为 8 个实例、320 个分表,单表行数在 4 千万行。SQL 单次执行在 2s 左右,在业务并发升高时响应超过 10s,业务无法接受。
数据保留周期还需更长,单表面临的数据量会更大,业务响应时间会更长,这将面临再次进行分库分表。业务有较多的 OLAP 类统计需求,二次分表和新增统计需求增加了逻辑复杂度。TiDB 上不用在考虑分库分表,不用写更加复杂的逻辑。
TiDB 可实现快速水平扩展,不用 DBA 进行复杂的数据搬迁,对业务可做到几乎无感知。
准备和测试
对现有问题梳理后结合现在 TiDB 特点我们想到可以试试 TiDB,随即今年 9 月搭建 4.0.6 版本的 TiDB 功能和新能测试,用来与现有 MySQL 进行对比。
主要对查询统计类业务进行压测;
环境: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 定期备份。
版权声明: 本文为 InfoQ 作者【TiDB 社区干货传送门】的原创文章。
原文链接:【http://xie.infoq.cn/article/a93cd2d2eeb68af87876d730b】。文章转载请联系作者。
评论