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

作者：孙晓光，北京知乎软件架构师。
来源：http://itindex.net/

知乎，在古文中意为“你知道吗？” ，它是中国的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毫秒或更短：即使对于执行时间最长的长尾查询，也会发生这种情况。
容忍误报：这意味着系统可以为用户调出许多有趣的帖子，即使有些帖子被错误地过滤掉了。

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

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

勘探
【1.3万亿条数据查询如何做到毫秒级响应？】为了构建具有上述功能的理想架构，我们在之前的架构中集成了三个关键组件：

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

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

MySQL分片的缺点：