1.3万亿条数据查询如何作到毫秒级响应？

时间 2020-01-15

标签 1.3 万亿数据查询如何作到毫秒响应繁體版

原文原文链接

关注微信公众号“程序员黄小斜”，选择“置顶或者星标”前端

一块儿成为更好的本身！程序员

<figure data-block="true" data-editor="7p19l" data-offset-key="d6t0m-0-0" contenteditable="false">面试

</figure>算法

做者：孙晓光数据库

出处：http://itindex.net/编程

知乎，在古典中文中意为“你知道吗？”，它是中国的 Quora，一个问答网站，其中各类问题由用户社区建立，回答，编辑和组织。segmentfault

做为中国最大的知识共享平台，咱们目前拥有 2.2 亿注册用户，3000 万个问题，网站答案超过 1.3 亿。后端

随着用户群的增加，咱们的应用程序的数据大小没法实现。咱们的 Moneta 应用程序中存储了大约 1.3 万亿行数据（存储用户已经阅读过的帖子）。缓存

因为每个月累计产生大约 1000 亿行数据且不断增加，这一数字将在两年内达到 3 万亿。在保持良好用户体验的同时，咱们在扩展后端方面面临严峻挑战。安全

在这篇文章中，我将深刻探讨如何在如此大量的数据上保持毫秒级的查询响应时间，以及 TiDB 是一个开源的 MySQL 兼容的 NewSQL 混合事务/分析处理（ HTAP）数据库，如何为咱们提供支持得到对咱们数据的实时洞察。

我将介绍为何咱们选择 TiDB，咱们如何使用它，咱们学到了什么，优秀实践以及对将来的一些想法。

咱们的痛点

</figure>

本节介绍了咱们的 Moneta 应用程序的体系结构，咱们尝试构建的理想体系结构，以及数据库可伸缩性做为咱们的主要难点。

系统架构要求

知乎的 Post Feed 服务是一个关键系统，用户能够经过该系统接收网站上发布的内容。

后端的 Moneta 应用程序存储用户已阅读的帖子，并在知乎的推荐页面的帖子流中过滤掉这些帖子。

Moneta 应用程序具备如下特征：

须要高可用性数据：Post Feed 是第一个出现的屏幕，它在推进用户流量到知乎方面发挥着重要做用。
处理巨大的写入数据：例如，在高峰时间每秒写入超过 4 万条记录，记录数量天天增长近 30 亿条记录。
长期存储历史数据：目前，系统中存储了大约 1.3 万亿条记录。随着每个月累积约 1000 亿条记录而且不断增加，历史数据将在大约两年内达到 3 万亿条记录。
处理高吞吐量查询：在高峰时间，系统处理平均每秒在 1200 万个帖子上执行的查询。
将查询的响应时间限制为 90 毫秒或更短：即便对于执行时间最长的长尾查询，也会发生这种状况。
容忍误报：这意味着系统能够为用户调出许多有趣的帖子，即便有些帖子被错误地过滤掉了。

考虑到上述事实，咱们须要一个具备如下功能的应用程序架构：

高可用性：当用户打开知乎的推荐页面时，找到大量已经阅读过的帖子是一种糟糕的用户体验。
出色的系统性能：咱们的应用具备高吞吐量和严格的响应时间要求。
易于扩展：随着业务的发展和应用程序的发展，咱们但愿咱们的系统能够轻松扩展。

勘探

为了构建具备上述功能的理想架构，咱们在以前的架构中集成了三个关键组件：

代理：这会将用户的请求转发给可用节点，并确保系统的高可用性。
缓存：这暂时处理内存中的请求，所以咱们并不老是须要处理数据库中的请求。这能够提升系统性能。
存储：在使用 TiDB 以前，咱们在独立的 MySQL 上管理咱们的业务数据。随着数据量的激增，独立的 MySQL 系统还不够。而后咱们采用了 MySQL 分片和 Master High Availability Manager（ MHA）的解决方案，可是当每个月有 1000 亿条新记录涌入咱们的数据库时，这个解决方案是不可取的。

MySQL Sharding 和 MHA 的缺点

MySQL 分片和 MHA 不是一个好的解决方案，由于 MySQL 分片和 MHA 都有它们的缺点。

MySQL 分片的缺点：

应用程序代码变得复杂且难以维护。
更改现有的分片键很麻烦。
升级应用程序逻辑会影响应用程序的可用性。

MHA 的缺点：

咱们须要经过编写脚本或使用第三方工具来实现虚拟 IP（VIP）配置。
MHA 仅监视主数据库。
要配置 MHA，咱们须要配置无密码安全 Shell（ SSH）。这可能会致使潜在的安全风险。
MHA 不为从属服务器提供读取负载平衡功能。
MHA 只能监视主服务器（而不是从主服务器）是否可用。

在咱们发现 TiDB 并将数据从 MySQL 迁移到 TiDB 以前，数据库可伸缩性仍然是整个系统的弱点。

什么是 TiDB？

</figure>

TiDB 平台是一组组件，当它们一块儿使用时，它们将成为具备 HTAP 功能的 NewSQL 数据库。

</figure>

TiDB 平台架构

在 TiDB 平台内部，主要组件以下：

TiDB 服务器是一个无状态的 SQL 层，它处理用户的 SQL 查询，访问存储层中的数据，并将相应的结果返回给应用程序。它与 MySQL 兼容而且位于 TiKV 之上。
TiKV 服务器是数据持久存在的分布式事务键值存储层。它使用 Raft 共识协议进行复制，以确保强大的数据一致性和高可用性。
TiSpark 集群也位于 TiKV 之上。它是一个 Apache Spark 插件，可与 TiDB 平台配合使用，支持商业智能（BI）分析师和数据科学家的复杂在线分析处理（OLAP）查询。
放置驱动程序（PD）服务器是由 etcd 支持的元数据集群，用于管理和调度 TiKV。

除了这些主要组件以外，TiDB 还拥有一个工具生态系统，例如用于快速部署的 Ansible 脚本，用于从 MySQL 迁移的 Syncer 和 TiDB 数据迁移。

以及用于收集对 TiDB 群集进行的逻辑更改并提供增量备份的 TiDB Binlog。复制到下游（TiDB，Kafka 或 MySQL）。

TiDB 的主要功能包括：

水平可扩展性。
MySQL 兼容的语法。
具备强一致性的分布式事务。
云原生架构。
使用 HTAP 进行最小提取，转换，加载（ ETL）。
容错和 Raft 恢复。
在线架构更改。

咱们如何使用 TiDB

</figure>

在本节中，我将向您展现如何在 Moneta 的架构中运行 TiDB 以及 Moneta 应用程序的性能指标。

咱们架构中的 TiDB

</figure>

知乎的 Moneta 应用程序中的 TiDB 架构

咱们在系统中部署了 TiDB，Moneta 应用程序的总体架构变为：

顶层：无状态和可伸缩的客户端 API 和代理。这些组件易于扩展。
中间层：软状态组件和分层 Redis 缓存做为主要部分。当服务中断时，这些组件能够经过恢复保存在 TiDB 群集中的数据来自我恢复服务。
底层：TiDB 集群存储全部有状态数据。它的组件高度可用，若是节点崩溃，它能够自我恢复其服务。

在该系统中，全部组件都是可自我恢复的，整个系统具备全局故障监视机制。而后，咱们使用 Kubernetes 来协调整个系统，以确保整个服务的高可用性。

TiDB 的性能指标

因为咱们在生产环境中应用了 TiDB，所以咱们的系统具备高可用性和易于扩展性，而且系统性能获得显著改善。例如，在 2019 年 6 月为 Moneta 应用程序采用一组性能指标。

在高峰时间每秒写入 40,000 行数据：

</figure>

每秒写入的数据行（数千）

在高峰时段每秒检查 30,000 个查询和 1200 万个帖子：

</figure>

每秒写入的数据行（数千）

第 99 百分位响应时间约为 25 毫秒，第 999 百分位响应时间约为 50 毫秒。实际上，平均响应时间远远小于这些数字，即便对于须要稳定响应时间的长尾查询也是如此。

</figure>

第 99 百分位响应时间

</figure>

第 999 百分位响应时间

咱们学到了什么

</figure>

咱们迁移到 TiDB 并不是顺利，在这里，咱们想分享一些经验教训。

更快地导入数据

咱们使用 TiDB 数据迁移（DM）来收集 MySQL 增量 Binlog 文件，而后使用 TiDB Lightning 将数据快速导入 TiDB 集群。

令咱们惊讶的是，将这 1.1 万亿条记录导入 TiDB 只用了四天时间。若是咱们逻辑地将数据写入系统，可能须要一个月或更长时间。若是咱们有更多的硬件资源，咱们能够更快地导入数据。

减小查询延迟

完成迁移后，咱们测试了少许的读取流量。当 Moneta 应用程序首次上线时，咱们发现查询延迟不符合咱们的要求。为解决延迟问题，咱们与 PingCap 工程师合做调整系统性能。

在此过程当中，咱们积累了宝贵的数据和数据处理知识：

有些查询对查询延迟很敏感，有些则否则。咱们部署了一个单独的 TiDB 数据库来处理对延迟敏感的查询。（其余非延迟敏感的查询在不一样的 TiDB 数据库中处理。）这样，大型查询和对延迟敏感的查询在不一样的数据库中处理，前者的执行不会影响后者。
对于没有理想执行计划的查询，咱们编写了 SQL 提示来帮助执行引擎选择最佳执行计划。
咱们使用低精度时间戳 Oracle（ TSO）和预处理语句来减小网络往返。

评估资源

在咱们尝试 TiDB 以前，咱们没有分析咱们须要多少硬件资源来支持 MySQL 端的相同数据量。

为了下降维护成本，咱们在单主机 - 单从机拓扑中部署了 MySQL。相反，在 TiDB 中实现的 Raft 协议至少须要三个副本。

所以，咱们须要更多的硬件资源来支持 TiDB 中的业务数据，咱们须要提早准备机器资源。

一旦咱们的数据中心设置正确，咱们就能够快速完成对 TiDB 的评估。

对 TiDB 3.0 的指望

</figure>

在知乎，反垃圾邮件和 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 相比的写入和查询延迟：

</figure>

在 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 逻辑，所以咱们能够用更少的节点管理应用程序。

之前，咱们使用了七个物理节点，但如今咱们只须要五个。即便咱们使用商用硬件，这些功能也可提高性能。

下一步是什么

</figure>

TiDB 是一个与 MySQL 兼容的数据库，所以咱们能够像使用 MySQL 同样使用它。

因为 TiDB 的横向可扩展性，如今咱们能够自由扩展咱们的数据库，即便咱们有超过一万亿的记录来应对。

到目前为止，咱们已经在咱们的应用程序中使用了至关多的开源软件。咱们还学到了不少关于使用 TiDB 处理系统问题的知识。

咱们决定参与开发开源工具，并参与社区的长期发展。基于咱们与 PingCAP 的共同努力，TiDB 将变得更增强大。

做者：孙晓光简介：知乎搜索后端负责人，目前承担知乎搜索后端架构设计以及工程团队的管理工做。曾多年从事私有云相关产品开发工做，关注云原生技术，TiKV 项目 Committer。出处： http://itindex.net/ 原文连接： https://dzone.com/articles/le...

关注微信公众号【程序员黄小斜】回复“2019”领取我这两年整理的学习资料

涵盖自学编程、求职面试、Java技术、计算机基础和考研等8000G资料合集。

微信公众号

我的公众号：程序员黄小斜

微信公众号【程序员黄小斜】新生代青年汇集地，程序员成长充电站。做者黄小斜，职业是阿里程序员，身份是斜杠青年，但愿和更多的程序员交朋友，一块儿进步和成长！专一于分享技术、面试、职场等成长干货，这一次，咱们一块儿出发。

关注公众号后回复“2019”领取我这两年整理的学习资料，涵盖自学编程、求职面试、算法刷题、Java技术学习、计算机基础和考研等8000G资料合集。

技术公众号：程序员江湖

微信公众号【程序员江湖】英雄不问出处，编程不看出身。这里是自学编程爱好者的汇集地，也是程序员IT学习资源的藏经阁。点击关注，一块儿成为更优秀的程序员！

关注公众号【程序员江湖】后回复「Java」、「Python」、「C++」、「大数据」、「算法」、「AI」、「Android」、「前端」、「iOS」、「BAT」、「校招」、「笔试」、「面试」、「计算机基础」、「LeetCode」等关键字能够获取对应的免费程序员学习资料。