Skip to content

Latest commit

 

History

History
56 lines (33 loc) · 5.52 KB

user-case-yuanfudao.md

File metadata and controls

56 lines (33 loc) · 5.52 KB
title author date summary tags category url weight logo customer customerCategory
TiDB 在猿辅导数据快速增长及复杂查询场景下的应用实践
猿辅导
2017-08-01
TiDB 是一个很有野心的项目,从无到有的解决了 MySQL 过去遇到的扩展性问题,在很多场合下也有 OLAP 的能力,省去了很多数据仓库搭建成本和学习成本。
互联网
case
/case/user-case-yuanfudao/
20
/images/blog-cn/customers/yuanfudao-logo.png
猿辅导
教育

猿辅导是国内拥有最多中小学生用户的在线教育机构,旗下有猿题库、小猿搜题、猿辅导三款在线教育 APP,为用户提供在线题库、拍照搜题、名师在线辅导相关的服务。其中,猿辅导 APP 已经有超过 116 万付费用户,提供小学英语、奥数,和初中高中全学科的直播辅导课程,全国任何地区的中小学生,都可以享受在家上北京名师辅导课的服务。

海量的题库、音视频答题资料、用户数据以及日志,对猿辅导后台数据存储和处理能力都提出了严峻的要求。

猿辅导的业务决定了其后台系统具有以下特点:

  • 数据体量大,增速快,存储系统需要能够灵活的水平扩展;

  • 有复杂查询,BI 方面的需求,可以根据索引,例如城市、渠道等,进行实时统计;

  • 数据存储要具备高可用、高可运维性,实现自动故障转移。

在最初方案选型时,猿辅导初期考虑用单机 MySQL。但根据业务发展速度预估,数据存储容量和并发压力很快就会达到单机数据库的处理瓶颈。如果在 MySQL 上加入分库中间件方案,则一定要指定 sharding key,这样是无法支持跨 shard 的分布式事务。同时 proxy 的方案对业务层的侵入性较强,开发人员必须了解数据库的分区规则,无法做到透明。

除此之外,分库分表很难实现跨 shard 的聚合查询,例如全表的关联查询、子查询、分组聚合等业务场景,查询的复杂度需要转嫁给开发者。即使某些中间件能实现简单的 join 支持,但是仍然没有办法保证查询的正确性。另外广播是一个没有办法 Scale 的方案,当集群规模变大,广播的性能开销是很大的。同时,传统 RDBMS 上 DDL 锁表的问题,对于数据量较大的业务来说,锁定的时间会很长,如果使用 gh-ost 这样第三方工具来实现非阻塞 DDL,额外的空间开销会比较大,而且仍然需要人工的介入确保数据的一致性,最后切换的过程系统可能会有抖动。可以说,运维的复杂性是随着机器数量指数级增长,而扩容复杂度则是直接转嫁给了 DBA。

最终,猿辅导的后台开发同学决定寻求一个彻底的分布式存储解决方案。通过对社区方案的调研,猿辅导发现分布式关系型数据库 TiDB 项目。

TiDB 是一款定位于在线事务处理/在线分析处理(HTAP)的融合型数据库产品,具备在线弹性水平扩展、分布式强一致性事务、故障自恢复的高可用、跨数据中心多活等核心特性;对业务没有任何侵入性,能优雅的替换传统的数据库中间件、数据库分库分表等 Sharding 方案,并在此过程中保证了事务的 ACID 特性。同时它也让开发运维人员不用关注数据库 Scale 的细节问题,专注于业务开发,极大的提升研发的生产力。用户可以把 TiDB 当作一个容量无限扩展的单机数据库,复杂的分布式事务和数据复制由底层存储引擎来支持,开发者只需要集中精力在业务逻辑的开发上面。

图为 TiDB 与传统的 MySQL 中间件方案的一些对比

TiDB 集群主要分为三个组件:TiDB Server、TiKV Server、PD Server。

TiDB 整体架构图

TiDB Server 负责处理 SQL 请求,随着业务的增长,可以简单的添加 TiDB Server 节点,提高整体的处理能力,提供更高的吞吐。TiKV 负责存储数据,随着数据量的增长,可以部署更多的 TiKV Server 节点解决数据 Scale 的问题。PD 会在 TiKV 节点之间以 Region 为单位做调度,将部分数据迁移到新加的节点上。所以企业在业务的早期,可以只部署少量的服务实例,随着业务量的增长,按照需求添加 TiKV 或者 TiDB 实例。

在实际上线的部署设置中,猿辅导选择了 2 TiDB + 3 TiKV + 3 PD 的架构,随着业务数据的增加可以弹性扩容,数据条数每天 500w,日常库中数亿条记录,峰值 QPS 1000。

猿辅导的用户端会做一些直播过程的音视频质量的数据收集,比如丢包,延迟,质量打分。然后客户端把这些数据发回服务器,服务器把这些数据存到 TiDB 上。

猿辅导研发副总裁郭常圳看来:“TiDB 是一个很有野心的项目,从无到有的解决了 MySQL 过去遇到的扩展性问题,在很多场合下也有 OLAP 的能力,省去了很多数据仓库搭建成本和学习成本。这在业务层是非常受欢迎的。”对于接下来的计划,猿辅导预计在其他分库分表业务中,通过 syncer 同步,进行合并,然后进行统计分析。

实际上,类似猿辅导这种场景的并不是第一家,在互联网快速发展下,大量的企业面对着业务激增的情况。TiDB 灵活的水平扩展能力,能够满足企业业务快速发展的需要。