1.3万亿条数据查询怎样做到毫秒级响应？

发布时间：2022-03-28 19:23:08 所属栏目：编程来源：互联网

导读：作为中国最大的知识共享平台，我们目前拥有 2.2 亿注册用户，3000 万个问题，网站答案超过 1.3 亿。随着用户群的增长，我们的应用程序的数据大小无法实现。我们的 Moneta 应用程序中存储了大约 1.3 万亿行数据（存储用户已经阅读过的帖子）。由于每月累计

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

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

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

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

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

Moneta 应用程序具有以下特征：

· 需要高可用性数据：Post Feed 是第一个出现的屏幕，它在推动用户流量到知乎方面发挥着重要作用。

· 处理巨大的写入数据：例如，在高峰时间每秒写入超过 4 万条记录，记录数量每天增加近 30 亿条记录。

· 长期存储历史数据：目前，系统中存储了大约 1.3 万亿条记录。随着每月累积约 1000 亿条记录并且不断增长，历史数据将在大约两年内达到 3 万亿条记录。

· 处理高吞吐量查询：在高峰时间，系统处理平均每秒在 1200 万个帖子上执行的查询。

· 将查询的响应时间限制为 90 毫秒或更短：即使对于执行时间最长的长尾查询，也会发生这种情况。

· 容忍误报：这意味着系统可以为用户调出许多有趣的帖子，即使有些帖子被错误地过滤掉了。

考虑到上述事实，我们需要一个具有以下功能的应用程序架构：

· 高可用性：当用户打开知乎的推荐页面时，找到大量已经阅读过的帖子是一种糟糕的用户体验。

· 出色的系统性能：我们的应用具有高吞吐量和严格的响应时间要求。

· 易于扩展：随着业务的发展和应用程序的发展，我们希望我们的系统可以轻松扩展。

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

MySQL 分片的缺点：

· 应用程序代码变得复杂且难以维护。

· 更改现有的分片键很麻烦。

· 升级应用程序逻辑会影响应用程序的可用性。

MHA 的缺点：

· 我们需要通过编写脚本或使用第三方工具来实现虚拟 IP（VIP）配置。

· MHA 仅监视主数据库。

· 要配置 MHA，我们需要配置无密码安全 Shell（ SSH）。这可能会导致潜在的安全风险。

· MHA 不为从属服务器提供读取负载平衡功能。

· MHA 只能监视主服务器（而不是从主服务器）是否可用。

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

（编辑：厦门网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!

MySQL自增列主从不一致	XtraBackup的加量备份
MySQL TEXT、DATE、SE	MySQL5.7+keepalived+