首页 文章 排行 更新 赞助VIP 自定义收藏 搜索狂魔 广告位购买【请先登录!】 注册 登录

    1.3 万亿条数据查询,如何做到毫秒级响应? - 大咖技术

    浏览人数:109 更新时间:2021-06-12 所属栏目:每天一看


知乎,在古典中文中意为“你知道吗?”,它是中国的 Quora,一个问答网站,其中各种问题由用户社区创建,回答,编辑和组织。
作为中国最大的知识共享平台,我们目前拥有 2.2 亿注册用户,3000 万个问题,网站答案超过 1.3 亿。

随着用户群的增长,我们的应用程序的数据大小无法实现。我们的 Moneta 应用程序中存储了大约 1.3 万亿行数据(存储用户已经阅读过的帖子)。

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

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

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

我们的痛点


本节介绍了我们的 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?


TiDB 平台是一组组件,当它们一起使用时,它们将成为具有 HTAP 功能的 NewSQL 数据库。

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


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

我们架构中的 TiDB



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

我们在系统中部署了 TiDB,Moneta 应用程序的整体架构变为:

  • 顶层:无状态和可伸缩的客户端 API 和代理。这些组件易于扩展。
  • 中间层:软状态组件和分层 Redis 缓存作为主要部分。当服务中断时,这些组件可以通过恢复保存在 TiDB 群集中的数据来自我恢复服务。
  • 底层:TiDB 集群存储所有有状态数据。它的组件高度可用,如果节点崩溃,它可以自我恢复其服务。

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


TiDB 的性能指标

你来打破0评论