我们选择了一个分布式SQL数据库来补充MySQL

VIPKid是一家总部位于中国的在线英语教育公司，为4-15岁的儿童及其父母提供服务。通过我们的在线课堂门户和视频聊天平台，中国的孩子们可以从美国或加拿大流利的英语教师那里获得25分钟的英语课程。目前，我们有70多万名付费学生。

我们使用MySQL作为后端数据库。但是，随着我们的应用程序数据快速增长，独立MySQL的存储容量成为一个瓶颈，不能再满足我们的应用程序要求。我们在核心应用程序上尝试了MySQL分片，但很难对分片数据运行多维查询。因此，我们采用了TiDB，这是一个开源的分布式SQL数据库，支持混合事务/分析处理(HTAP)工作负载。TiDB支持在大表上创建二级索引。我们可以使用它来执行多维SQL查询。对于分片，我们不再需要担心跨分片的多维查询。

我是VIPKid的一名高级DBA工程师，我想讨论一下如何使用TiDB对分片数据进行多维查询，并增强我们的实时分析能力。首先，我将讨论我们使用TiDB的应用场景，然后我将分享TiDB给我们带来的好处。

在此之前，我们使用MySQL作为后端数据库。但随着我们的数据量急剧增加，独立的MySQL数据库存储容量有限，无法为我们提供服务。

因此，我们寻找了一个新的数据库，发现TiDB是一个很好的解决方案。

TiDB是由PingCAP及其开源社区构建的开源分布式SQL数据库。它与MySQL兼容，具有水平可伸缩性、强一致性和高可用性。它是适用于在线事务处理(OLTP)和在线分析处理(OLAP)工作负载的一站式解决方案。您可以在这里了解更多关于TiDB架构的信息。

它与MySQL协议、常见的MySQL功能和MySQL生态系统兼容。要将生产应用程序迁移到TiDB，我们只需修改少量代码。

它支持水平缩放。TiDB体系结构设计将计算与存储分离，使我们能够根据需要在线单独横向扩展或扩展计算或存储容量。扩展过程对应用程序运营和维护人员是透明的。

它适用于各种需要与大规模数据保持高可用性和强一致性的使用案例。

下图显示了数据量较大、写入高度并发的应用场景。要理解此场景，请考虑我们的课堂故障排除系统。该系统实时收集课堂事件的信息，包括学生进入和离开教室的时间以及服务初始化的时间。此信息通过家长和教师申请报告。应用程序团队可以使用此信息快速定位教室系统中的故障，并进行一些故障排除，例如切换线路，以确保课堂质量。

该系统目前的峰值工作负载约为每秒10,000个事务(TPS)，每天增加约1800万行数据。此表仅保留最近两个月的数据。目前，单个表大约有12亿行数据。这个数据量其实太大了。如果我们把这些数据存储在MySQL中，维护成本会很高，所以我们把所有的系统数据都迁移到了TiDB上。

在迁移过程中，我们对表架构进行了一些细微的更改。我们删除了原始的自动增量ID，并且在构建表时，通过指定配置提前分散了区域。当存在高并发写入时，此方法可避免写入热点。在TiDB 4.0中，TiDB Dashboard使查找热点变得更容易，因为它以图形方式显示写入卷和读取卷等信息。

在我们公司的早期阶段，我们在许多核心应用程序上实现了分片-例如排课。通常，当我们进行分片时，只有一个应用程序列被用作分片键。但是，日程安排任务可能涉及多个维度，包括教室、教师、学生和课程。此外，其他应用程序也可以访问数据。例如，当教师应用程序访问数据时，数据会显示在教师视图中。但是，如果根据学生的视图拆分数据，教师的访问请求将广播到所有分片，这在网上是不允许的。

我们尝试了几种解决方案，但收效甚微。最后，我们使用TiDB Data Migration(DM)从上游到下游实时复制所有分片的表，并将它们合并到一个全局表中。无论是在管理应用运行平台上，还是在应用指标监控系统上，所有的多维查询都运行在TiDB上。

DM分片的逻辑很简单。DM在线拉取所有分片的binlog，然后根据阻止列表和允许列表匹配需要复制的binlog事件。然后，DM匹配预定义的路由规则，重写规则，然后将规则应用于下游全局表。

我们改变了DM延迟监控机制。在大多数情况下，当我们合并碎片时，复制延迟在200毫秒以内。

如果你想了解我们DM修改的细节，你可以加入Slake上的TiDB社区。

如果您使用过MySQL，您可能知道在MySQL中维护大表的成本很高；因此，一般来说，许多公司都会进行分层数据归档。现在，我们根据特定的应用程序和读写卷将数据划分为多个级别。我们将冷数据、暖数据和在线读取流量放在TiDB中。

要传输数据，必须确保冷数据和热数据的表模式相同。然而，冷数据要比热数据多得多。这可能会影响表架构更改的效率。例如，如果您已经更改了热数据的表模式，比如添加一列，而您想要对冷数据执行同样的操作，则成本将非常高-可能是热数据的10倍甚至更多。所以我们决定使用TiDB来做这件事。一方面，TiDB的DDL有一些有用的功能。例如，您可以在几秒内添加或减去字段。另一方面，借助TiDB的水平可伸缩性，我们可以为每个应用程序重用一组TiDB归档集群。

此场景主要由商业智能(BI)分析师和一些BI平台使用。我们使用DM将所有在线数据复制到TiDB。借助TiDB的水平可伸缩性和计算下推能力，我们可以进行实时数据分析。

TiFlash是TiDB的扩展分析引擎和列存储。包含TiFlash的TiDB数据库允许您执行实时HTAP分析。

实时一致性强。TiDB将更新的数据实时复制到TiFlash，以确保TiFlash处理最新(而不仅仅是最新)数据。

自动存储选择。TiDB智能地决定是选择行存储还是选择列存储来处理各种查询场景，而无需您的干预。

我用五个TiKV节点、一个TiFlash节点和一个包含2.5亿行数据的表进行了一个简单的测试。我试着数了数桌子上的记录。当我在TiKV上按指数查询时，我花了40多秒才得到结果。但是，当我在单个TiFlash节点中查询时，仅用了10秒。如果我添加更多的TiFlash节点，速度会进一步提高。

我们过去有一个用于BI的集群，但它运行的是较旧版本的TiDB。我们已经用带有TiFlash的TiDB 4.0群集取代了它。下表显示了新旧群集负载相同时的资源分配情况。通过使用TiFlash部署新群集，我们的总成本降低了35%。

如果存在涉及全表扫描的SQL查询，则TiKV集群负载将会增加。这可能会增加OLTP查询的总体响应时间。现在，我可以添加一个TiFlash节点，为相应集群中的大表自动添加一个TiFlash副本。现在，如果SQL查询涉及全表扫描，数据可以首先转到TiFlash。这确保了TiKV受到的影响尽可能小。

如果您的SQL语句包含TiFlash尚未实现的函数，则不可能下推运算符。SQL语句只使用TiFlash的功能来加速计算。

PingCAP团队优化了大表和小表之间的连接操作。他们将不断优化其余的联接操作。

TiDB4.0引入了TiDB Dashboard，这是一个带有各种内置小部件的图形界面，让您可以轻松地诊断、监控和管理集群。TiDB Dashboard使TiDB更易于开箱即用，并为您提供有关数据和数据库性能的重要见解。

在单个界面中，您可以检查分布式群集的运行时状态并管理该群集，包括：

过去，TiDB只支持逻辑备份，备份大量数据效率不高。现在，TiDB的Backup&；Restore(BR)工具使用物理备份，令人印象深刻。BR是一种分布式备份和恢复工具，可提供高备份和恢复速度-10 TB数据的备份和恢复速度为1 Gb/s或更高。

PingCAP建议，为了进行备份，我们在BR机器和所有TiKV机器上使用相同的共享存储。我们备份了一个大约2.4 TB的TiDB实例。备份花了几个小时。不过，我认为我们可以进一步优化这一时间，因为平均备份速度约为每秒80MB，这可能会受到当前串行连接SCSI(SAS)磁盘带宽的限制。如果我们晚些时候调整，会更快。上图显示了BR备份的每个目录的大小。如您所见，总体备份大小为700多GB。

随着我们的应用程序数据快速增长，独立MySQL的存储容量不再能满足我们的应用程序要求。在我们对核心应用程序进行分片之后，很难对分片数据运行多维查询。因此，我们采用了开源的、分布式的HTAP数据库TiDB，它具有MySQL兼容性、横向可伸缩性、高可用性、强一致性等特点。

多亏了TiDB对分割表的多维SQL查询的支持，我们不需要担心跨分片的多维查询。此外，TiDB还具有强大的功能和生态系统工具。它们有助于提高我们的查询性能，轻松解决群集问题，并快速备份数据。