行业：直播

作者：嘉庆许（在戈DBA）

杂种：跑黄;编辑：佳林陈，汤姆德湾

成立于2014年，大家是一家位于新加坡的快速发展社交网络公司。基于我们强大的音频和视频处理，全球实时传输和内容交付网络（CDN）技术，BIGO推出了BIGO LIVE（实时视频流），喜欢（短窗体视频）和IMO（视频会议））。BIGO现在每月拥有近4亿活跃的用户，我们的产品和服务涵盖了150多个国家和地区。

我们的业务的快速增长是我们的基础设施和软件的贡献是分不开的。随着我们的应用程序数据的迅速增长，我们尝试phxsql.，mysql，和鼠兔要管理我们的数据，但它们在水平可扩展性或复杂查询方面的弱点让我们失望。

谢谢Tidb.，开源，MySQL兼容，水平可扩展的数据库，具有强的一致性，我们能够更好地处理我们的数据。在本文中，我们将讨论我们如何从TIDB中受益及其新功能TiDB 4.0。

为什么我们选择TIDB

在我们使用TIDB之前，我们尝试了PHXSQL，MySQL和Pika，但他们有这些缺点：

• phxsql：
  • 很难向外扩展和碎片
  • 无法处理每秒高疑问（QPS）
  • 几乎不明意
• mysql：
  • 难以扩展
  • 不擅长执行复杂的SQL查询
• 皮卡：
  • 难以执行复杂的查询和范围查询

我们寻找一个新的解决方案，发现TIDB，一个开源，分布式，混合交易/分析处理（htap）数据库，是一个不错的选择。我们采用TIDB，因为它具有以下优势：

• 这是与MySQL协议兼容。要将生产应用程序迁移到TIDB，我们只需要修改少量代码。
• 它适用于需要各种用例强一致性和高可用性具有大规模数据。
• 它支持或进行水平扩展。TIDB的体系结构将计算从存储中分开，并使我们能够根据需要在线单独扩展或缩放计算或存储容量。
• 它很容易部署。

TIDB 4.0在BIGO

Tidb.是一个开源，分布式SQL数据库，提供横向扩展性，高可用性和实时HTAP。在2020年5，TiDB发布了4.0版本的GA，标志着其历史上的一个里程碑。

今年年初，我们开始使用TiDB 4.0测试版。我们创建了一个测试集群，这将伴随着TiDB的最新开发版本迭代。因此，我们升级到TiDB 4.0 GA其发布后不久。

我们采取了大胆的一步，并在生产环境中部署了两个TiDB集群，多为分析处理。

• 一个用于分析网络监测指标。此群集的数据量快速增长，其SQL语句主要是分析。该应用程序还需要快速响应。
• 另一个被部署为大数据系统的下游存储。通过大数据工具处理后，提供TIDB集群中的数据用于在线实时服务。单个表的数据量很大。

在TIDB 4.0中，Tiup.用于集群部署，泵和排水机用于根据Binlogs以及基于Binlog的不同大洲的数据复制数据TIFLASH.用于实时数据分析。我们在我们的系统中广泛使用这些TiDB 4.0组件。

为什么我们升级到TiDB 4.0

新版本的数据库可以将不稳定性带到现有系统。但是，在审慎和深入考虑之后，我们决定升级到TIDB 4.0。主要因素是我们的应用要求和有效的数据库维护。

申请要求

当申请团队提出新要求时，作为DBA，我们总是尽力满足他们的需求。

所使用的应用程序开发人员抱怨说，TiDB的字符集排序并没有按预期方式工作。他们是对的。4.0之前，TiDB无法确定在其分拣信件的情况。它处理过的大写和小写的方式相同。多亏了4.0，TiDB现在支持通过区分大小写字符集和归类。

在TIDB 4.0中，悲观事务模型是电子商务和金融平台的一个重要特征，通常可用。使用TIDB 4.0，应用程序不再需要焦点不一致或数据冲突。

维护要求

使用TIDB 4.0，维护也更容易。

Tiup：更好的包裹管理

Tiup.是一个包管理器，使我们能够仅使用单行TiUP命令部署和维护TIDB。它使管理TIDB组件简单灵活。

此外，我们可以用TiUP寻找到整个集群的状态。我们不必单独去，在其状态每个簇和外观。

备份和恢复

TIDB 4.0的另一个好特征是备份和恢复（BR）。BR是用于分布式备份和恢复TIDB群集数据的命令行工具。与MyDumper或Loader相比，BR更适合具有巨大数据量的群集。

此前TiDB 4.0，我们只能执行备份，并通过mydumper或创建磁盘快照，这使得它很难为数据库管理员维护数据库恢复。尽管我们想尝试我们的核心应用与TiDB，缺乏完整的备份和恢复功能，防止这样做我们。

随着BR，我们将在更多的我们的应用程序的使用TiDB并进一步和更自信地去与这个分布式数据库。

tiflash：实时htap

如果你问我是我最喜欢Tidb 4.0的功能，答案是绝对的TIFLASH.。TIFLASH是使TIDB成为真正HTAP数据库的组件。

TIDB有两个存储引擎：TIKV，ROW商店和TIFLASH，列商店。Tiflash是TIKV的柱状延伸，其根据TIKV根据TIKV的数据筏共识算法。

我们通常将请求分为两种类型：在线事务处理（OLTP）和在线分析处理（OLAP）。我们可能会认为，实时在线应用程序的请求是OLTP工作负载，大数据分析的摘要是OLAP工作负载。但情况真的是真的吗？在实际使用方案中，为了满足操作要求，许多在线应用程序会对实时报告进行查询。

只需使用大数据工具，这些查询可能需要t + 1甚至是t + n天来处理。这在实时无处可去。其中一个解决方案是在OLTP存储上进行查询。其他解决方案包括修改索引，将相同的数据复制到不同的存储器，或将相同的数据写入不同的表。这些解决方案效率低或麻烦。TiFlash给了我们一个新的选项：将柱状副本，以实现实时分析。

上面的图片是从一个实时应用大量的SQL语句。这是100线长，并且包含大量的表格和通过...分组条文，一些条件和一个和聚合函数。通常，请求在Online MySQL数据库或TIDB数据库中处理，以TIKV为唯一的引擎，可能需要几分钟甚至几小时完成。但是通过柱状存储引擎的柱状存储引擎，我们成功将处理时间降低到50秒。此外，由于Tiflash中的数据从TIKV复制，并且筏子保证了它们的一致性，因此TIFlash查询不仅快速运行，而且还返回一致，实时结果。

TiDB也可以与我们现有的大数据系统相结合。它提供Tispark.，一个层修建了为TiDB上运行的Apache的火花。我们可以用TiSpark访问存储层，包括TiKV和TiFlash。

在TIDB 4.0 GA中，TIFLASH推出了两个新参数，让它推下更多的运营商并合并更多区域请求。（一个区域是TIDB的存储引擎中数据存储的基本单位。）通过配置这些参数，我们可以显着提高性能。在我们的测试中，TIFLASH将性能提高100％，查询时间从25秒降至11〜12秒。这意味着在几乎实时分析了在线数据。与tiflash相比，提取，变换，负载我们的大数据系统（ETL）的处理要经过很长的数据管道。如果没有双向数据验证，这可能会导致数据不一致，甚至数据丢失。现在，我们所有的应用程序都倾向于选择TiFlash，而不是传统的大数据解决方案。

总之，我们每个在线应用程序的TIDB 4.0集群至少有一个TIFlash副本。即使Tiflash Replica下降，我们仍然可以向TIKV推下请求。对于DBA，数据库稳定性是优先级，并且TIFlash确保数据库保持工作 - 即使在困难的情况下也会保持工作。这是我们选择TIDB 4.0和TIFLASH的重要原因。

我们未来的TIDB 4.0计划

TIDB 4.0提供了许多我们尚未探索的可能性。在本节中，我会讨论我们如何使用TIDB 4.0计划我们的下一步。

TICDC：多源复制

由于我们的企业遍布多个大陆，我们的应用程序通常必须处理多源复制。以前，我们使用过泵和排水机要实现复制，但是当数据从多个来源写入时，我们也必须重复使用书面数据。

在这种情况下，泵和排水机不是理想的解决方案。他们有部署和可用性问题，消耗太多资源，并产生不希望的Binlogs。使用TIDB 4.0，我们将尝试Ticdc.中，变更数据捕获工具，复制多个TiDB簇之间和各种数据源之间的数据。我们也将开发我们自己的一些特点，如解决冲突和数据合并。

放置司机的服务发现

许多应用程序使用TiKV和TiFlash作为存储引擎，以及TiDB服务器是一个无状态的服务。大多数应用程序都集成了这个无状态的服务，使用代理式服务将请求转发到不同的服务器TiDB实现负载均衡。这样的结构是不是很优雅。当代理与容器连接，所述群集可能通过容器或用其他方法进行弹性调度。在这种情况下，代理可能不是无法检测到后端的变化速度不够快。

放置司机（PD）解决了这个问题，因为它提供了ettd.基于接口。我们可以在这些接口中找到可用的TIDB节点。当群集弹性缩小时，例如在高峰时段期间，它可以快速缩放无状态TIDB节点。然后，PD可以快速发现TIDB服务器，我们可以从客户端找到服务，并将增加的流量路由到该服务器。

通过这种方式，缩放服务可以在短时间内进行在线，我们不必改变大部分应用程序代码。如果我们以旧方法执行此操作，则缩放数据库必须注册服务，然后再次在代理中注册，这可能会延迟整个过程。

TIDB仪表板：数据库工作负载看起来像什么

TiDB仪表板是一个图形界面，具有内置窗口小部件，让用户轻松诊断，监视和管理群集。在一个接口中，用户可以检查分布式群集的运行时状态并管理群集，包括：

• 快速查找集群热点
• 分析SQL语句的执行性能
• 查看慢查询
• 生成群集诊断报告
• 搜索和导出日志
• 分析实例

作为一名DBA，我有时碰到与应用程序开发者的冲突。开发商可能会坚持认为，他们没有做任何要求，没有看到变化，因此，该数据不具有热点。TiDB 4.0之前，我们没有办法来证明或反驳这种说法。现在有了TiDB仪表盘，我们可以清楚地看到什么数据库工作负载的样子。

例如，拍摄小部件，关键可视化器。这是一个可视化诊断工具，可以让用户随着时间的推移，并提出了数据的热图观察其TiDB集群的读写量。

在这个热图：

• X轴表示时间。
• Y轴表示的键范围，与键范围到表和索引之间的映射。
• 颜色代表键范围的读或写的体积。在色彩明亮，更高的读或写卷。

密钥可视化器在用户中受欢迎。我们听说用户甚至为关键视觉器创建了一个Emoji HeatMap：

使用键可视化器，我们可以观察到关键范围的工作负载。因此，当应用团队声称他们的数据没有热点时，DBA可以向他们展示热图并说明。毕竟，应用程序可能无法意识到群集工作量和趋势。这个完整的工作量快照带来了很多洞察力。

当然，TIDB仪表板有其他好处。它准确地监控慢询问，使我们能够搜索所有实例的日志，甚至可以显示分析数据作为火焰图一个单一的点击。有了这个强大的工具，我们可以更好地解决群集异常，保证数据库的稳定运行。

结论

自从我们开始使用TIDB以来已经超过一年。它的MySQL兼容性那强一致性和易于使用的功能已经在各种情况下帮助我们交付和质量的结果，我们的预期。

我们期待着TIDB的未来创新，我们将继续与该项目密切合作，以提高我们的全球业务的增长。