使用HTAP数据库将实时查询延迟从0.5 s减少到0.01 s
Autohome是中国汽车消费者的领先在线目的地。它＆＃39;是世界上访问过的汽车网站之一。我们提供专业生产和用户生成的内容，全面的汽车库和广泛的汽车上市信息，涵盖整个汽车购买和所有权周期。
Autohome社区论坛是我们最古老的应用之一，每日访问1亿+每日访问和10亿+日常接口呼叫。随着我们的数据大小迅速增长，SQL Server成为我们的数据库瓶颈。碎片DIDN＆＃39; t符合我们的应用要求，并缩放数据库容量影响应用程序。我们寻找一个新的数据库解决方案。
在我们比较TIDB，Apache点火和蟑螂后，我们选择TIDB，开源，分布式，混合事务/分析处理（HTAP）数据库。由于其水平可扩展性，现在我们可以轻松扩展我们的数据库，我们的事务性第99百分位延迟在12毫秒内。
2020年，TIDB还担任我们的大销售促销的潜在储存，每秒数十万次查询（QPS）。我们的实时查询延迟从0.5秒降至0.01秒。 TIDB＆＃39;第99百分位数在20毫秒内。
这篇文章介绍了TIDB如何帮助我们实现数据库缩放和实时分析，以及封面：
在过去的14年里，自动全民社区论坛增长到1亿+职位和10亿+回复。它拥有1000万+日常活跃的用户，每天1000万+访问，10亿+平均每日接口呼叫。我们在SQL Server中存储了论坛＆＃39; s数据。由于我们的业务迅速增长，我们遇到了越来越多的数据库问题。我们需要解决两个紧急问题：分片和缩放。
Autohome论坛回复数据库存储回复帖子。当SQL Server＆＃39;单个表太大时，数据库性能劣化。要解决此问题，我们将根据帖子ID分离回复数据库。结果是回复数据库中100次碎片和1,000多个表。
但是，我们开发了应用程序，并且更改了应用程序需求，并且当我们想要实现一些应用程序需求时，分片无法满足我们的需求。我们希望数据在逻辑上位于一个表中。
近年来，随着我们业务的快速增长，我们的数据量显着增加。但是硬盘的容量有限，并且在每台服务器上，我们只能添加有限的磁盘。结果，我们有时不得不添加更大容量的存储服务器。但是，这种方法很复杂，并且每次更改服务器时，仍然需要注意相关的应用程序。我们希望扩展数据库存储不会影响应用程序。另外，大容量数据库服务器很昂贵。
在2019年，我们研究了三种流行的分布式SQL数据库：TiDB，Apache Ignite和CockroachDB。经过多次测试，我们选择了TiDB，因为：
TiDB与MySQL协议兼容，因此我们可以像使用MySQL一样使用TiDB。
TiDB是由PingCAP及其开源社区构建的开源，云原生，分布式SQL数据库。它与MySQL兼容，具有水平可伸缩性，强一致性和高可用性。它是用于在线事务处理（OLTP）和在线分析处理（OLAP）工作负载的一站式解决方案。您可以在此处了解有关TiDB架构的更多信息。
我们可以随时将节点添加到集群中，并且很容易更改节点。
它可以轻松处理100亿多行数据。例如，您可以查看Zhihu案例研究。
SQL Server使用发布/订阅复制模型，而TiDB使用Raft算法来实现100％的强数据一致性。当大多数数据副本可用时，TiDB可以实现自动故障恢复。
TiDB是同时针对OLTP和OLAP方案的HTAP数据库。 TiDB的分析引擎TiFlash使用户可以执行实时分析。
我们在TiDB上进行了许多功能，性能，异常和应用程序访问测试。我们在OLTP，OLAP和异常情况下的测试结果表明TiDB符合我们的数据库要求。
我们在OLTP场景中针对2000万行数据和500个并发线程测试了TiDB。
如下图所示，TiDB的第99个百分位响应时间在16 ms之内。这满足了我们的应用要求。当数据量增加时，TiDB表现出更大的优势。另外，我们可以添加TiDB或TiKV节点以提高读写性能。
为了比较TiDB与MySQL，我们进行了50 GB TPC-H测试。测试结果表明，TiDB与MySQL相比具有很大的优势。在下表中，以粗体显示每个查询的优越性能：
我们在异常停机期间测试了PD和TiKV的性能。我们发现PD和TiKV的停机时间对应用程序影响很小，并且群集可以自动从故障中恢复。
我们制定了详细的迁移计划，并从SQL Server迁移到TiDB。如果您想了解有关我们迁移过程的更多信息，可以加入Slack上的TiDB社区。为了确保在将应用程序部署到生产环境后不会发生错误，我们对应用程序进行了一些更改。然后，我们优化了每个SQL语句，以便它们可以达到最佳索引。通过这样做，对于十亿行数据，我们的OLTP应用程序第99个百分点的响应时间在12毫秒以内，第99.9个百分点的响应时间在62毫秒以内。
在2019年9月，我们在生产环境中运行了分布式数据库TiDB。从那时起，它一直稳定运行。
2020年8月18日，汽车之家举行了为时三小时的促销晚会。促销晚会包括多项互动活动，例如讨价还价，红包和抽奖。这些应用程序涉及数百万用户，系统达到了数十万个QPS的峰值。促销活动发放了数百万份奖品和红包。由于每轮讨价还价和抽奖活动都很短暂，因此交易量非常大，并且这些应用涉及对账和冲销，因此对系统设计提出了很高的要求。
基于这些应用场景，系统设计需要合适的数据持久层。正如我在下面详细解释的那样，我们在两个城市的三个数据中心（DC）中部署了TiDB作为基础存储。
跨两个城市体系结构的三个DC是用于生产DC，城市内灾难恢复中心和远程灾难恢复中心的高可用性灾难恢复解决方案。在此部署中，三个DC相互连接。如果一个DC发生故障或发生灾难，则其他DC可以正常运行并接管关键应用程序或所有应用程序。与同一城市规划中的多数据中心相比，在两个城市中部署的三个数据中心具有跨城市的高可用性，并且可以在城市自然灾害中生存。
TiDB提供了两个存储引擎：TiKV行存储引擎和TiFlash列存储引擎。 TiDB实时将更新的数据从TiKV复制到TiFlash，以确保TiKV和TiFlash之间的数据具有很强的一致性。对于HTAP资源隔离，我们可以根据需要在不同的计算机上部署TiKV和TiFlash。
TiDB体系结构将计算与存储分开，因此我们可以根据需要分别扩展或扩展在线计算或存储容量。扩展过程对应用程序操作和维护人员是透明的。
TiDB与MySQL 5.7协议，MySQL的共同功能以及MySQL生态系统兼容。我们能够以最小的代码更改将应用程序迁移到TiDB，在某些情况下甚至根本没有更改。此外，TiDB提供了一系列数据迁移工具，以帮助轻松地将应用程序数据迁移到TiDB中。
在汽车之家，用户产品中心是第一个使用TiDB的业务部门，它将核心应用程序论坛的答复从SQL Server迁移到TiDB。车主价格应用程序从MySQL迁移到TiDB。我们在迁移，使用和优化TiDB方面具有经验。 TiDB在汽车之家中享有很高的声誉。
TiDB使用Raft算法来支持两个城市配置中的三个DC，并确保TiDB集群数据一致且高度可用。另外，由于同一城市中的DC具有较低的网络延迟，因此我们可以同时向它们分配应用程序流量，并控制Region Leader和PD Leader的分配。这样一来，位于同一城市的DC可以共同加载应用程序流量。
为了促进销售，我们在两个城市的三个DC中部署了TiDB，并提供了五个数据副本。我们的集群组件如下：
TiFlash是TiDB的列式存储引擎。这使TiDB成为真正的HTAP数据库。 TiFlash提供与TiKV相同的快照隔离一致性级别，并确保读取最新数据。
在大型促销活动中，我们使用TiFlash在大屏幕上显示实时数据。
TiCDC是一种开放源代码功能，它通过订阅TiKV中的更改日志来将TiDB的增量更改复制到下游平台。它还提供了TiCDC开放协议，以支持订阅TiKV数据更改的其他系统。
在我们的集群中，它将TiDB集群数据实时复制到下游的MySQL数据库。 TiCDC的复制延迟在几秒钟之内，满足了我们对在线促销应用程序的实时要求。
如果无法改进应用程序，则将MySQL数据库用作备份。容灾能力。
在将TiDB投入生产以进行大规模促销之前，我们在两个城市的三个DC中对TiDB 3.0.16、4.0.1、4.0.2和4.0.3进行了多次测试。在这些测试中，我们遇到了一个问题和一个错误。在PingCAP团队的帮助下，我们迅速修复了它们。
由于Sysbench没有重新连接功能，因此我们无法使用它来测试某些方案。我们使用了Sysbench和一个应用程序仿真程序。
我们根据实际应用场景制定了测试计划。主要测试项目如下：
我们在这里不会详细讨论测试结果，但是我们的结论是，无论是单节点故障还是IDC故障，群集都可以在大约30秒内恢复并继续提供满足应用程序需求的服务。
在大型促销活动中，TiDB表现出色，并很好地支持了我们的讨价还价，红包和抽奖活动：
TiFlash将面板实时分析的查询响应时间从0.5 s减少到0.01 s。
随着我们社区论坛的访问和发布持续增加，巨大的数据量给我们的SQL Server数据库带来了巨大压力。为了扩展数据库，我们从SQL Server迁移到TiDB。我们不再需要担心麻烦的数据库分片。
我们已经运行TiDB超过两年了，它已用于重要的应用程序中，例如论坛回复，资源池和朋友管理。我们还在2020年的大型促销应用中在两个城市的三个DC中部署了TiDB。该解决方案保证了我们数据的高可用性，并帮助我们实现了实时HTAP。我们可以根据需要扩展或扩展数据库。此外，TiCDC的高可用性和低延迟以及对大型集群的支持给我们留下了深刻的印象。
如果您有任何疑问或需要有关我们经验的详细信息，可以加入Slack上的TiDB社区。
