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



猿辅导是国内拥有最多中小学生用户的在线教育机构，旗下有猿题库、小猿搜题、猿辅导三款在线教育 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 当作一个容量无限扩展的单机数据库，复杂的分布式事务和数据复制由底层存储引擎来支持，开发者只需要集中精力在业务逻辑的开发上面。

![](media/user-case-yuanfudao/1.jpeg)

<div class="caption-center">图为 TiDB 与传统的 MySQL 中间件方案的一些对比</div>

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

![](media/user-case-yuanfudao/2.jpeg)

<div class="caption-center">TiDB 整体架构图</div>

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 灵活的水平扩展能力，能够满足企业业务快速发展的需要。
