13 万亿条数据查询如何做到毫秒级响应？.docx

《13 万亿条数据查询如何做到毫秒级响应？.docx》由会员分享，可在线阅读，更多相关《13 万亿条数据查询如何做到毫秒级响应？.docx（12页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、1.3万亿条数据查询，如何做到毫秒级响应？;：亿行数据且不断增长，这一数字将在两年内达到3万亿。在保持良好用户体验的同时，我们在扩展后端方面面临严峻挑战。在这篇文章中，我将深入探讨如何在如此大量的数据上保持毫秒级的查询响应时间，以及TiDB是一个开源的MySQL兼容的NewSQL混合事务/分析处理（HTAP）数据库，如何为我们提供支持获得对我们数据的实时洞察。我将介绍为什么我们选择TiDB，我们如何使用它，我们学到了什么，优秀实践以及对未来的一些想法。#我们的痛点本节介绍了我们的Moneta应用程序的体系结构，我们尝试构建的理想体系结构，以及数据库可伸缩性作为我们的主要难点。系统架构要求知乎的

2、PostFeed服务是一个关键系统，用户可以通过该系统接收网站上发布的内容。后端的Moneta应用程序存储用户已阅读的帖子，并在知乎的推荐页面的帖子流中过滤掉这些帖子。Moneta应用程序具有以下特征：需要高可用性数据：PostFeed是第一个出现的屏幕，它在推动用户流量到知乎方面发挥着重要作用。处理巨大的写入数据：例如，在高峰时间每秒写入超过4万条记录，记录数量每天增加近30亿条记录。长期存储历史数据：目前，系统中存储了大约1.3万亿条记录。随着每月累积约1000亿条记录并且不断增长，历史数据将在大约两年内达到3万亿条记录。处理高吞吐量查询：在高峰时间，系统处理平均每秒在1200万个帖子上执

3、行的查询。将查询的响应时间限制为90毫秒或更短：即使对于执行时间最长的长尾查询，也会发生这种情况。容忍误报：这意味着系统可以为用户调出许多有趣的帖子，即使有些帖子被错误地过滤掉了。考虑到上述事实，我们需要一个具有以下功能的应用程序架构：高可用性：当用户打开知乎的推荐页面时，找到大量已经阅读过的帖子是一种糟糕的用户体验。出色的系统性能：我们的应用具有高吞吐量和严格的响应时间要求。易于扩展：随着业务的发展和应用程序的发展，我们希望我们的系统可以轻松扩展。勘探为了构建具有上述功能的理想架构，我们在之前的架构中集成了三个关键组件：代理：这会将用户的请求转发给可用节点，并确保系统的高可用性。缓存：这暂时

4、处理内存中的请求，因此我们并不总是需要处理数据库中的请求。这可以提高系统性能。存储：在使用TiDB之前，我们在独立的MySQL上管理我们的业务数据。随着数据量的激增，独立的MySQL系统还不够。然后我们采用了MySQL分片和MasterHighAvailabilityManager（MHA）的解决方案，但是当每月有1000亿条新记录涌入我们的数据库时，这个解决方案是不可取的。#MySQLSharding和MHA的缺点MySQL分片和MHA不是一个好的解决方案，因为MySQL分片和MHA都有它们的缺点。MySQL分片的缺点：应用程序代码变得复杂且难以维护。更改现有的分片键很麻烦。升级应用程序逻辑

5、会影响应用程序的可用性。MHA的缺点：我们需要通过编写脚本或使用第三方工具来实现虚拟IP（VIP）配置。MHA仅监视主数据库。要配置MHA，我们需要配置无密码安全Shell（SSH）。这可能会导致潜在的安全风险。MHA不为从属服务器提供读取负载平衡功能。MHA只能监视主服务器（而不是从主服务器）是否可用。在我们发现TiDB并将数据从MySQL迁移到TiDB之前，数据库可伸缩性仍然是整个系统的弱点。#什么是TiDB？TiDB平台是一组组件，当它们一起使用时，它们将成为具有HTAP功能的NewSQL数据库。在TiDB平台内部，主要组件如下：TiDB服务器是一个无状态的SQL层，它处理用户的SQL查

6、询，访问存储层中的数据，并将相应的结果返回给应用程序。它与MySQL兼容并且位于TiKV之上。TiKV服务器是数据持久存在的分布式事务键值存储层。它使用Raft共识协议进行复制，以确保强大的数据一致性和高可用性。TiSpark集群也位于TiKV之上。它是一个ApacheSpark插件，可与TiDB平台配合使用，支持商业智能（BI）分析师和数据科学家的复杂在线分析处理（OLAP）查询。放置驱动程序（PD）服务器是由etcd支持的元数据集群，用于管理和调度TiKV。除了这些主要组件之外，TiDB还拥有一个工具生态系统，例如用于快速部署的Ansible脚本，用于从MySQL迁移的Syncer和TiD

7、B数据迁移。以及用于收集对TiDB群集进行的逻辑更改并提供增量备份的TiDBBinlog。复制到下游（TiDB，Kafka或MySQL）。TiDB的主要功能包括：水平可扩展性。MySQL兼容的语法。具有强一致性的分布式事务。云原生架构。使用HTAP进行最小提取，转换，加载（ETL）。容错和Raft恢复。在线架构更改。#我们如何使用TiDB在本节中，我将向您展示如何在Moneta的架构中运行TiDB以及Moneta应用程序的性能指标。我们架构中的TiDB知乎的Moneta应用程序中的TiDB架构我们在系统中部署了TiDB，Moneta应用程序的整体架构变为：顶层：无状态和可伸缩的客户端API和代

8、理。这些组件易于扩展。中间层：软状态组件和分层Redis缓存作为主要部分。当服务中断时，这些组件可以通过恢复保存在TiDB群集中的数据来自我恢复服务。底层：TiDB集群存储所有有状态数据。它的组件高度可用，如果节点崩溃，它可以自我恢复其服务。在该系统中，所有组件都是可自我恢复的，整个系统具有全局故障监视机制。然后，我们使用Kubernetes来协调整个系统，以确保整个服务的高可用性。TiDB的性能指标由于我们在生产环境中应用了TiDB，因此我们的系统具有高可用性和易于扩展性，并且系统性能得到显著改善。例如，在2019年6月为Moneta应用程序采用一组性能指标。在高峰时间每秒写入40,000行

9、数据：每秒写入的数据行（数千）在高峰时段每秒检查30,000个查询和1200万个帖子：每秒写入的数据行（数千）第99百分位响应时间约为25毫秒，第999百分位响应时间约为50毫秒。实际上，平均响应时间远远小于这些数字，即使对于需要稳定响应时间的长尾查询也是如此。第99百分位响应时间第999百分位响应时间#我们学到了什么我们迁移到TiDB并非顺利，在这里，我们想分享一些经验教训。更快地导入数据我们使用TiDB数据迁移（DM）来收集MySQL增量Binlog文件，然后使用TiDBLightning将数据快速导入TiDB集群。令我们惊讶的是，将这1.1万亿条记录导入TiDB只用了四天时间。如果我们逻

10、辑地将数据写入系统，可能需要一个月或更长时间。如果我们有更多的硬件资源，我们可以更快地导入数据。减少查询延迟完成迁移后，我们测试了少量的读取流量。当Moneta应用程序首次上线时，我们发现查询延迟不符合我们的要求。为解决延迟问题，我们与PingCap工程师合作调整系统性能。在此过程中，我们积累了宝贵的数据和数据处理知识：有些查询对查询延迟很敏感，有些则不然。我们部署了一个单独的TiDB数据库来处理对延迟敏感的查询。（其他非延迟敏感的查询在不同的TiDB数据库中处理。）这样，大型查询和对延迟敏感的查询在不同的数据库中处理，前者的执行不会影响后者。对于没有理想执行计划的查询，我们编写了SQL提示来

11、帮助执行引擎选择最佳执行计划。我们使用低精度时间戳Oracle（TSO）和预处理语句来减少网络往返。评估资源在我们尝试TiDB之前，我们没有分析我们需要多少硬件资源来支持MySQL端的相同数据量。为了降低维护成本，我们在单主机-单从机拓扑中部署了MySQL。相反，在TiDB中实现的Raft协议至少需要三个副本。因此，我们需要更多的硬件资源来支持TiDB中的业务数据，我们需要提前准备机器资源。一旦我们的数据中心设置正确，我们就可以快速完成对TiDB的评估。#对TiDB3.0的期望在知乎，反垃圾邮件和Moneta应用程序的架构相同。我们在用于生产数据的反垃圾邮件应用程序中尝试了TiDB3.0（Ti

12、DB3.0.0-rc.1和TiDB3.0.0-rc.2）的候选版本中的Titan和TablePartition。Titan缩短了延迟反垃圾邮件应用程序一直受到严重的查询和写入延迟折磨。我们听说TiDB3.0将引入Titan，一种键值存储引擎，用于在使用大值时减少RocksDB（TiKV中的底层存储引擎）的写入放大。为了尝试这个功能，我们在TiDB3.0.0-rc.2发布后启用了Titan。下图分别显示了与RocksDB和Titan相比的写入和查询延迟：在RocksDB和Titan中编写和查询延迟统计数据显示，在我们启用Titan后，写入和查询延迟都急剧下降。这真是太惊人了！当我们看到统计数据时

13、，我们无法相信自己的眼睛。表分区改进了查询性能我们还在反垃圾邮件应用程序中使用了TiDB3.0的表分区功能。使用此功能，我们可以按时将表分成多个分区。当查询到来时，它将在覆盖目标时间范围的分区上执行。这大大提高了我们的查询性能。让我们考虑一下如果我们将来在Moneta和反垃圾邮件应用程序中实施TiDB3.0会发生什么。Moneta应用程序中的TiDB3.0TiDB3.0具有诸如gRPC中的批处理消息，多线程Raftstore，SQL计划管理和TiFlash等功能。我们相信这些将为Moneta应用增添光彩。gRPC和多线程Raftstore中的批处理消息Moneta的写入吞吐量超过每秒4万次交易

14、（TPS），TiDB3.0可以批量发送和接收Raft消息，并且可以在多个线程中处理RegionRaft逻辑。我们相信这些功能将显著提高我们系统的并发能力。SQL计划管理如上所述，我们编写了大量SQL提示，以使查询优化器选择最佳执行计划。TiDB3.0添加了一个SQL计划管理功能，可以直接在TiDB服务器中将查询绑定到特定的执行计划。使用此功能，我们不需要修改查询文本以注入提示。TiFlash在TiDBDevCon2019上，我第一次听说TiFlash是TiDB的扩展分析引擎。它使用面向列的存储技术来实现高数据压缩率，并在数据复制中应用扩展的Raft一致性算法以确保数据安全性。由于我们拥有高写入

15、吞吐量的海量数据，因此我们无法每天使用ETL将数据复制到Hadoop进行分析。但是对于TiFlash，我们乐观地认为我们可以轻松分析我们庞大的数据量。反垃圾邮件应用程序中的TiDB3.0与Moneta应用程序的巨大历史数据大小相比，反垃圾邮件应用程序具有更高的写入吞吐量。但是，它仅查询过去48小时内存储的数据。在此应用程序中，数据每天增加80亿条记录和1.5TB。由于TiDB3.0可以批量发送和接收Raft消息，并且它可以在多个线程中处理RegionRaft逻辑，因此我们可以用更少的节点管理应用程序。以前，我们使用了七个物理节点，但现在我们只需要五个。即使我们使用商用硬件，这些功能也可提升性能。#下一步是什么TiDB是一个与MySQL兼容的数据库，因此我们可以像使用MySQL一样使用它。由于TiDB的横向可扩展性，现在我们可以自由扩展我们的数据库，即使我们有超过一万亿的记录来应对。到目前为止，我们已经在我们的应用程序中使用了相当多的开源软件。我们还学到了很多关于使用TiDB处理系统问题的知识。我们决定参与开发开源工具，并参与社区的长期发展。基于我们与PingCAP的共同努力，TiDB将变得更加强大。