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

减少查询延迟
完成迁移后，我们测试了少量的读取流量。当Moneta应用程序首次上线时，我们发现查询延迟不符合我们的要求。为解决延迟问题，我们与PingCap工程师合作调整系统性能。
在此过程中，我们积累了宝贵的数据和数据处理知识：

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

评估资源
在我们尝试TiDB之前，我们没有分析我们需要多少硬件资源来支持MySQL端的相同数据量。为了降低维护成本，我们在单主机 - 单从机拓扑中部署了MySQL 。相反，在TiDB中实现的 Raft协议至少需要三个副本。因此，我们需要更多的硬件资源来支持TiDB中的业务数据，我们需要提前准备机器资源。
一旦我们的数据中心设置正确，我们就可以快速完成对TiDB的评估。
我们对TiDB 3.0的期望
在Zhihu ，反垃圾邮件和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相比的写入和查询延迟：

文章插图

在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逻辑，因此我们可以用更少的节点管理应用程序。以前，我们使用了七个物理节点，但现在我们只需要五个。即使我们使用商用硬件，这些功能也可提升性能。