永远有趣,永远在线:TiDB如何帮助爱奇艺传递流媒体视频

2018-10-18 iQiyi 互联网

工业:媒体和娱乐

作者:朱伯帅(爱奇艺高级基础设施工程师)

iQiyi它是中国的Netflix:中国的Netflix最大的在线视频点播平台.我们以“时时乐,时时好”为品牌口号,致力于为用户提供高分辨率、真实的媒体内容,包括电影、电视剧、综艺、纪录片、动画、旅游节目等。2018年3月29日,我们的公司在纳斯达克上市,募集了22.5亿美元。

由于我们的业务快速增长,我们的数据规模也大幅增长。这给我们的后端系统,尤其是MySQL集群带来了巨大的压力。我们经历了处理大量数据的痛苦,直到我们发现TiDB,兼容mysql的NewSQL混合事务和分析处理(HTAP)数据库,由PingCAP构建并支持。最后,我们可以适当地管理我们的数据。

目前,TiDB集群部署在我们数据库云团队的内部系统中。随着2018年4月其2.0版本的发布,TiDB已经被证明更加成熟,系统稳定性和查询效率都有所提高。在这篇文章中,我们将分享我们为什么选择TiDB,我们如何使用它,以及我们与PingCAP团队紧密合作的经验教训。

我们为什么选择TiDB

在TiDB之前,MySQL是我们用于生产环境的主要数据库解决方案。业务发展得如此之快,以至于我们的数据量激增,MySQL集群中出现了许多瓶颈。例如:

  • 一个独立的MySQL实例只支持有限的数据量。因此,我们必须删除过时的数据以保持数据库运行。
  • 表中的行数不断增加,导致查询性能下降。

为了支持我们快速增长的业务,我们迫切需要一个数据库:

  • 水平扩展
  • 高可用性
  • 兼容MySQL

TiDB选中了所有这些选项,事实上,它的性能超出了我们的预期。

TiDB是什么?

TiDB是一个开放源代码,NewSQL,可伸缩的混合事务和分析处理(HTAP)数据库由PingCAP团队和开源社区构建。它旨在打破OLTP数据库和OLAP数据库之间的传统分离,并提供一站式解决方案,支持对活动事务数据进行实时业务分析。

图1:TiDB平台架构

图1:TiDB平台架构

在TiDB平台内部,有几个组件:

  • TiDB集群由无状态TiDB实例组成,作为无状态SQL层处理用户的SQL查询,访问存储层中的数据,并返回相应的结果。它与MySQL兼容,并且位于TiKV之上。
  • TiKV集群由TiKV实例组成,是数据所在的分布式事务Key-Value存储层。无论数据来自哪里,最终都会存储在TiKV中。它使用一致性复制协议,保证数据一致性和容灾。
  • TiSpark集群也位于TiKV的顶部。它是一个Apache Spark插件,与TiDB平台一起工作,为BI分析师和数据科学家支持复杂的OLAP查询。

TiDB生态系统还拥有大量其他企业级工具,例如Ansible脚本快速部署,同步用于从MySQL无缝迁移,用于迁移异构数据的Wormhole,以及TiDB Binlog,这是一个收集binlog文件的工具。

我们如何使用TiDB?

场景一:风险监控中心中的TiDB

风险监控中心存储机器安全统计信息,包括来自不同维度的流量信息,如每个DC(数据中心)、每个IP地址、每个端口等。为了及时了解系统状态,应用程序会不时地执行一些复杂的查询。

在数据库评估过程中,我们比较了Apache Druid和TiDB,发现:

  • Druid通过Apache方解石适配器提供SQL支持;TiDB本地支持SQL。
  • 德鲁伊不支持ACID交易;TiDB保证了ACID的遵从性,数据随时随地准确可靠。
  • Druid实际上是一个依赖于额外存储引擎的计算引擎;数据无法实时更新。TiDB作为一个整体项目,使用TiKV作为其存储引擎,并提供数据的实时更新。
  • 德鲁伊在聚合查询方面不灵活,这对爱奇艺服务的数据分析至关重要;TiDB在聚合查询中表现良好,因此为我们分析数据提供了可靠的基础。
  • TiDB与MySQL协议高度兼容。用户可以通过现有的MySQL连接池组件访问TiDB。这意味着服务迁移成本低,开发效率高。

因此,我们决定在我们的风险监控中心部署TiDB。

部署过程

风险监控中心是爱奇艺第一个在生产环境中上线使用TiDB的项目,所以我们提出了以下计划:

  1. 为了确保数据的绝对安全,我们为TiDB集群设计了B方案:我们用TokuDB替换MySQL中的InnoDB,以提高它的写能力。然后我们部署了MySQL和TokuDB作为TiDB集群的辅助,并将TiDB集群中的数据与TiDB Binlog同步。尽管这不是最优的,因为带TokuDB的MySQL解决方案不能处理高峰期的数据增长,但我们将其设计为灾难恢复计划,而不考虑延迟。
  2. 前端部署内部开发的负载均衡器,充分利用多个TiDB节点的计算能力,保证TiDB节点的高可用性。
  3. 部署普罗米修斯Grafana监控TiDB集群状态。将Grafana连接到我们的内部警报平台,通过短消息和电子邮件即时通知运营团队警报信息。

问题和解决方案

在我们采用TiDB的过程中出现了以下问题,但很快得到了解决。

问题一:连接超时。

原因:这个问题是由于统计信息过时,无法选择最优查询计划而产生的。这是关系数据库的一个常见问题。有两种常见的解决方法:手动收集统计信息或使用计划执行提示。两者都是应用程序开发人员的额外工作负载。

解决方案:这个问题修正在TiDB的最新版本与改进的统计收集策略和自动分析。

问题二:在表中添加索引花了很长时间。

原因:

  • DDL执行信息没有及时更新。因此,在检查DDL操作进度时,我们得到了过时的信息。
  • 在某些情况下,大型region还需要额外的时间来添加索引。

解决方案:在我们向PingCAP开发团队报告了这个问题后,他们迅速做出了积极的回应。这个问题已经在TiDB的最新版本中修复了,增加了大区域的批分割功能。

TiDB在生产

  • 在风险监控中心迁移到TiDB后,我们成功升级了TiDB集群,修改了TiKV节点的参数。一般情况下,这些操作不会影响在线业务。

    在TIKV节点升级期间,发生一些错误(如“区域不可用)(稍后再试)和“TiKV服务器超时”。这是由于缓存信息的延迟,这在分布式系统中是不可避免的。但只要应用程序有重试机制,它就不会影响服务。

  • 令我们惊讶的是,无论数据增加多少(如图2所示),响应时间都是稳定的,这得益于TiDB的存储层TiKV的自动区域分割策略(如图3所示)。根据表的数据大小,TiDB中的表被自动分割成相同大小的几个部分(默认为96 MB,但可配置)。这些区域通过一系列复杂的调度算法调度到各个存储节点。对于一个特定的查询,无论其数据大小如何,TiDB都能快速定位到相应的Region,保证查询响应及时。

图2:风险监视中心中的数据增长

图2:风险监视中心中的数据增长

图3:在TiKV中自动划分表

图3:在TiKV中自动划分表

场景2:视频转码

视频转码数据库存储了转码过程中产生的历史数据,这些数据生成后需要进一步分析和处理。

难点:之前在MySQL集群中,由于存储容量有限,我们只能保留最近几个月的数据。因此我们失去了分析和处理早期数据的机会。

解决方案:为了解决这个问题,我们在2017年底部署了一个TiDB集群,并通过完全和增量导入的方式将数据迁移到TiDB集群。这种策略确保了以前的MySQL集群和新构建的TiDB集群之间的数据一致性。

在整个导入过程中,我们最初使用的是Mydumper + Loader,这是PingCAP开发的数据迁移工具。但是我们发现Loader对于我们的需求来说太慢了。

为了解决这个问题,PingCAP开发了TiDB Lightning,将Mydumper导出的数据转换为SST文件,并导入到TiKV节点。通过这种方式,数据迁移效率大大提高:1T的数据可以在5 - 6小时内成功迁移。视频转码稳定运行一段时间后,我们将所有流量切换到TiDB集群,并扩展了我们的服务。到目前为止,它运行得很顺利。

下图是TiDB的Lightning架构:

图4:TiDB Lightning实现架构

图4:TiDB Lightning实现架构

场景三:用户登录信息

在用户登录信息数据库项目中,我们遇到了一些棘手的问题,这些问题都通过TiDB解决了。

  • 该项目的数据量稳步增长;因此,MySQL主从集群在未来将无法容纳如此庞大的数据。
  • 由于单个表的数据量巨大,我们不得不在服务中使用分片,因此应用层的代码变得复杂,无法伸缩。

数据迁移到TiDB后,我们不再需要分片,应用程序代码也得到了简化。

迁移过程

在增量同步过程中,我们使用Syncer,它使用通配符聚合来自多个源和单个表中不同表的数据。它极大地简化了增量同步工作。

同步建筑结构如下:

图5:Syncer架构

图5:Syncer架构

但是,Syncer目前无法在Grafana中显示实时延迟信息。对于对同步延迟敏感的应用程序来说,这是一个缺点。好消息是PingCAP正在解决这个问题,他们重构了Syncer来自动处理表分区的主键冲突。使用Syncer和TiDB,用户可以快速实时同步多个MySQL集群的数据。

我们对数据库的高可用性有两个要求:

  • 即使服务器宕机,该服务仍然可用。
  • 该服务部署在多个数据中心,我们的数据中心有一个只读的辅助数据库,响应时间更短。

针对这些需求,TiDB有相应的解决方案:

  • TiDB集群部署在多个数据中心(如下图所示),保证了在线业务不受任何数据中心异常影响。
  • 在为每个TiKV节点设置标签后,TiDB集群在每个数据中心获得一个副本。PD集群将自动调度region并为Read操作找到合适的副本;这样,第二个要求就满足了。

为了保证数据迁移过程中的高可用性,我们使用排水器同步TiDB集群和MySQL集群中的数据。滤干器通过指定启动时间戳来支持反向同步。

图6:在多个数据中心部署TiDB

图6:在多个数据中心部署TiDB

在整个过程中,PingCAP团队给予了我们及时、专家级的帮助。他们帮助我们找到了问题所在,并给了我们建设性的建议。我们非常感谢他们的耐心和全力支持!

经验教训

TiDB最吸引人的特性是水平可伸缩性和高可用性。

独立数据库能够保存的数据是有限的。如果采用MySQL分片+代理的策略,无论代理在客户端还是服务器端,维护成本都会增加。

更糟糕的是,在很多情况下,查询效率无法满足性能要求。此外,代理不能很好地支持事务,不能保证数据一致性。

TiDB是MySQL分片+代理解决方案的完美替代。TiDB具有高可用性的服务和数据以及横向可扩展性,有效解决了大量数据带来的诸多问题。数据越多,TiDB的性能就越好。

结论

随着我们的业务呈指数级增长,我们疲于处理不断增加的数据。在对TiDB进行了仔细和严格的评估后,我们发现它是一个强大的数据库,在人们心中的份额正在增长。我们现在已经在生产环境中部署了TiDB。得益于TiDB的横向可扩展性和高可用性,我们不再担心数据量,更有信心为用户带来高质量的娱乐服务。

除了在上述应用程序中的使用,TiDB还在爱奇艺的其他应用程序中进行评估或测试。在某些用例中,TiDB需要处理OLTP和OLAP的混合场景,这是让TiSpark工作的好机会。我们感兴趣的一个开发领域是获得TiDB Binlog, TiDB的数据同步工具,以同步捻角羚HBase除了MySQL。为此,我们计划投资更多的TiDB,并发送一些拉请求TiDB社区.我们相信,凭借其强大的技术力量和专业、上进心强的团队,TiDB将在未来受到越来越多行业企业的欢迎。

准备好开始使用TiDB了吗?