作者:孙晓光 ,北京知乎软件架构师。
来源:http://itindex.net/
知乎,在古文中意为“你知道吗?”,它是中国的Quora:一个问答网站,其中各种问题由用户社区创建,回答,编辑和组织。作为中国最大的知识共享平台,知乎平台目前拥有2.2亿注册用户,3000万个问题,网站答案超过1.3亿。
随着用户群的增长,应用程序的数据大小无法评估,在一个名为Moneta的应用程序中存储了大约1.3万亿行数据(存储着用户已经阅读过的帖子)。由于每月累计产生大约1000亿行数据,且不断增长,这一数字将在两年内达到3万亿。
在保持良好用户体验的同时,我们在扩展后端方面面临严峻的挑战。
在这篇文章中,我将深入探讨如何在如此大量的数据上保持毫秒级的查询响应时间,以及TiDB是一个开源的MySQL兼容的NewSQL混合事务/分析处理( HTAP)数据库,如何为我们提供支持获得对我们数据的实时洞察。我将介绍为什么选择TiDB,如何使用它,学到了什么,最佳实践以及对未来的一些畅想。
我们的痛点
本节介绍了我们的Moneta应用程序的体系结构,我们尝试构建的理想体系结构,以及 数据库可伸缩性 作为我们技术团队的主要难点。
系统架构要求
知乎的Post Feed服务是一个关键系统,用户可以通过该系统接收网站上发布的内容。后端的Moneta应用程序存储用户已阅读的帖子,并在知乎的推荐页面的帖子流中过滤掉这些帖子。
Moneta应用程序具有以下特征:
考虑到上述事实,我们需要一个具有以下功能的应用程序架构:
勘探
为了构建具有上述功能的理想架构,我们在之前的架构中集成了三个关键组件:
MySQL Sharding和MHA的缺点
MySQL分片和MHA并不是一个好的解决方案,因为MySQL分片和MHA都有它们的缺点。
MySQL分片的缺点:
MHA的缺点:
在我们发现TiDB并将数据从MySQL迁移到TiDB之前,数据库可伸缩性仍然是整个系统的弱点。
什么是TiDB?
TiDB平台是一组组件,当它们一起使用时,它们将成为具有HTAP功能的NewSQL数据库。
图1 TiDB平台架构
在TiDB平台内部,主要组件如下:
除了这些主要组件之外,TiDB还拥有一个工具生态系统,例如用于快速部署的 Ansible脚本,用于从MySQL 迁移的 Syncer和 TiDB数据迁移,以及用于收集对TiDB群集进行的逻辑更改并提供增量备份的 TiDB Binlog。复制到下游(TiDB,Kafka或MySQL)。
TiDB的主要功能
TiDB的主要功能包括:
我们是如何使用TiDB的
在本节中,我将向您展示如何在Moneta的架构中运行TiDB以及Moneta应用程序的性能指标。
我们架构中的TiDB
我们在系统中部署了TiDB,Moneta应用程序的整体架构变为:
知乎的Moneta应用程序中的TiDB架构
在该系统中,所有组件都是可自我恢复的,整个系统具有全局故障监视机制。然后,我们使用 Kubernetes来协调整个系统,以确保整个服务的高可用性。
TiDB的性能指标
由于我们在生产环境中应用了TiDB,因此我们的系统具有高可用性和易于扩展性,并且系统性能得到显着改善。
例如,在2019年6月为Moneta应用程序采用一组性能指标:
在高峰时间每秒写入40,000行数据。
每秒写入的数据行(数千)
在高峰时段每秒检查30,000个查询和1200万个帖子。
每秒写入的数据行(数千)
第99百分位响应时间约为25毫秒,第999百分位响应时间约为50毫秒。实际上,平均响应时间远远小于这些数字,即使对于需要稳定响应时间的长尾查询也是如此。
第99百分位响应时间
第999百分位响应时间
我们学到了什么?
我们迁移到TiDB并非顺利。在这里,我们想分享一些经验教训。
更快地导入数据
我们使用TiDB数据迁移(DM)来收集MySQL增量binlog文件,然后使用 TiDB Lightning将数据快速导入TiDB集群。
令我们惊讶的是,将这1.1万亿条记录导入TiDB只用了四天时间。如果我们逻辑地将数据写入系统,可能需要一个月或更长时间。如果我们有更多的硬件资源,我们可以更快地导入数据。
减少查询延迟
完成迁移后,我们测试了少量的读取流量。当Moneta应用程序首次上线时,我们发现查询延迟不符合我们的要求。为解决延迟问题,我们与PingCap工程师合作调整系统性能。
在此过程中,我们积累了宝贵的数据和数据处理知识:
评估资源
在我们尝试TiDB之前,我们没有分析我们需要多少硬件资源来支持MySQL端的相同数据量。为了降低维护成本,我们在单主机 - 单从机拓扑中部署了MySQL。相反,在TiDB中实现的 Raft协议至少需要三个副本。因此,我们需要更多的硬件资源来支持TiDB中的业务数据,我们需要提前准备机器资源。
一旦我们的数据中心设置正确,我们就可以快速完成对TiDB的评估。
我们对TiDB 3.0的期望
在Zhihu,反垃圾邮件和Moneta应用程序的架构相同。我们在用于生产数据的反垃圾邮件应用程序中尝试了TiDB 3.0( TiDB 3.0.0-rc.1和 TiDB 3.0.0-rc.2)的候选版本中的 Titan和 Table Partition。
Titan缩短了延迟
反垃圾邮件应用程序一直受到严重的查询和写入延迟折磨。
我们听说TiDB 3.0将引入Titan,一种键值存储引擎,用于 在使用大值时减少 RocksDB(TiKV中的底层存储引擎)的写入放大。
为了尝试这个功能,我们在TiDB 3.0.0-rc.2发布后启用了Titan。下图分别显示了与RocksDB和Titan相比的写入和查询延迟:
在RocksDB和Titan中编写和查询延迟
统计数据显示,在我们启用Titan后,写入和查询延迟都急剧下降。这真是太惊人了!当我们看到统计数据时,我们无法相信自己的眼睛。
表分区改进了查询性能
我们还在反垃圾邮件应用程序中使用了TiDB 3.0的表分区功能。使用此功能,我们可以按时将表分成多个分区。当查询到来时,它将在覆盖目标时间范围的分区上执行。这大大提高了我们的查询性能。
让我们考虑一下如果我们将来在Moneta和反垃圾邮件应用程序中实施TiDB 3.0会发生什么。
Moneta应用程序中的TiDB 3.0
TiDB 3.0具有诸如gRPC中的批处理消息,多线程Raftstore,SQL计划管理和TiFlash等功能。我们相信这些将为Moneta应用增添光彩。
gRPC和多线程Raftstore中的批处理消息
Moneta的写入吞吐量超过每秒4万次交易(TPS).TiDB 3.0可以批量发送和接收Raft消息,并且可以在多个线程中处理Region Raft逻辑。我们相信这些功能将显着提高我们系统的并发能力。
SQL计划管理
如上所述,我们编写了大量SQL提示,以使查询优化器选择最佳执行计划。TiDB 3.0添加了一个SQL计划管理功能,可以直接在TiDB服务器中将查询绑定到特定的执行计划。使用此功能,我们不需要修改查询文本以注入提示。
TiFlash
在TiDB DevCon 2019上,我第一次听说TiFlash是TiDB的扩展分析引擎。它使用面向列的存储技术来实现高数据压缩率,并在数据复制中应用扩展的Raft一致性算法以确保数据安全性。
由于我们拥有高写入吞吐量的海量数据,因此我们无法每天使用ETL将数据复制到 Hadoop进行分析。但是对于TiFlash,我们乐观地认为我们可以轻松分析我们庞大的数据量。
反垃圾邮件应用程序中的TiDB 3.0
与Moneta应用程序的巨大历史数据大小相比,反垃圾邮件应用程序具有更高的写入吞吐量。但是,它仅查询过去48小时内存储的数据。在此应用程序中,数据每天增加80亿条记录和1.5 TB。
由于TiDB 3.0可以批量发送和接收Raft消息,并且它可以在多个线程中处理Region Raft逻辑,因此我们可以用更少的节点管理应用程序。以前,我们使用了七个物理节点,但现在我们只需要五个。即使我们使用商用硬件,这些功能也可提升性能。
下一步是什么
TiDB是一个与MySQL兼容的数据库,因此我们可以像使用MySQL一样使用它。由于TiDB的横向可扩展性,现在我们可以自由扩展我们的数据库,即使我们有超过一万亿的记录来应对。
到目前为止,我们已经在我们的应用程序中使用了相当多的开源软件。我们还学到了很多关于使用TiDB处理系统问题的知识。我们决定参与开发开源工具,并参与社区的长期发展。基于我们与PingCAP的共同努力,TiDB将变得更加强大和强大。