在ARM上运行扩展数据库作为MySQL的替代

2020-10-27 U-Next 互联网

行业:媒体及娱乐

作者: Birong Huang (U-Next高级工程师)

Transcreator:黄了编辑器:汤姆政府高级官员

在ARM上运行TiDB作为MySQL的替代品

U-Next是一个订阅式视频流媒体平台,在日本拥有最大的市场份额。在过去的几年里,我们的业务快速增长,而我们旧的IT基础设施已经跟不上了。我们需要升级我们的系统。

我们以前的MySQL集群很难扩展,当服务器有高并发时,集群就有高延迟。为了解决这些问题,我们将数据迁移到TiDB,这是一个开源的分布式SQL数据库,提供了水平可伸缩性和高性能。它支持MySQL协议,在我们的部门架构.有了TiDB,我们才能为用户提供更优质的服务。

在本文中,我将与您分享为什么我们选择将数据放在TiDB中并在ARM上运行它。此外,我还将提供TiDB在ARM上的详细基准测试。我希望我们的故事可以帮助您为您的应用程序找到正确的数据库解决方案。

为什么我们选择TiDB来取代MySQL

在迁移到TiDB之前,我们使用的是MySQL。为了提高数据库性能,我们选择了阿特拉斯一叉MySQL代理,来分割MySQL集群的读写请求。系统架构如下所示:

我们以前的系统架构

我们以前的系统架构

然而,这种实现有几个问题:

  • Atlas项目很少得到维护。如果出现了bug,我们的工程团队没有足够的资源自己解决它。
  • 向外扩展后端MySQL集群非常痛苦。
  • 随着服务器并发性的增加,延迟也急剧增加。

我们回顾了我们面临的困难和我们业务的新需求,并决定迁移到一个新的数据库:

  • 没有明显的瓶颈.我们想要一个水平可伸缩的数据库。例如,我们有一个每月增长1亿行的表。每个用户登录都需要访问这个表。如果数据库不能扩展,可能会严重影响我们的服务质量。
  • 是高可用性.我们希望能在线升级和扩展新的数据库。
  • 有一个活跃的社区和可用的技术支持.使用开源项目的一个潜在问题是,作者可能会停止维护它。因此,获得长期、可持续的技术支持非常重要。
  • 迁移成本低.迁移到一个新的数据库是麻烦和昂贵的,不仅因为我们需要支付新的硬件和软件,还因为我们必须修改应用程序代码。所以我们希望尽可能少地修改代码。

考虑到这些因素,我们认为TiDB是U-Next的最佳选择。TiDB是一个分布式数据库,提供水平可伸缩性和高可用性.此外,TiDB在GitHub上拥有超过2.5万颗星,这证明了它的社区是活跃的。最后但同样重要的是,它是MySQL兼容的。我们只需要修改一小部分代码就可以将应用程序集成到TiDB中。

为什么我们要在ARM上运行关键任务的TiDB数据库

正如我提到的,我们在ARM架构上运行TiDB。因为大多数公司的服务器都使用x86,所以我们在ARM上运行数据库似乎有些不寻常。我们选择ARM有三个主要原因:成本、兼容性和维护。

  • ARM处理器比较便宜,所以更适合中小型企业。
  • TiDB已经在ARM上正式测试和验证PingCAP, TiDB背后的团队发布了官方基准测试报告对于ARM64和x86-64,并确认TiDB与ARM没有兼容性问题。
  • 手臂是可靠的.多年来,U-Next一直使用ARM作为其分布式存储平台,并且进展顺利。我们的工程团队在维护ARM方面经验丰富。

因此,我们决定在ARM上运行关键任务TiDB,就像我们的其他应用程序一样。

TiDB在ARM和x86上的基准测试

为了确保TiDB在我们的应用程序中与ARM配合良好,我们在ARM和x86架构的服务器之间进行了基准测试。我们设置我们的测试环境如下:

手臂 x86
CPU 2台32核华为鲲鹏920处理器 两个英特尔2650年v4核心处理器(12)。
由于英特尔的超线程技术在美国,x86实际上有48个可用内核。
NUMA 四个节点 两个节点
内存 128 GB 128 GB
磁盘 2块SSD系统盘
1个NVMe数据盘
2块SSD系统盘
1个NVMe数据盘
网络 这些服务器来自同一个供应商,所以它们的网络条件是相同的。

基于我们自己的应用程序模型,我们使用轨迹来模拟在线请求负载。每个客户端每秒发送一个请求。我们测试了一个包含3亿行样本数据的表。每个操作包括一个得到,一个帖子和一个方法。我们总共发送了200,000个API请求。

下图显示了每秒请求(RPS)的结果。x轴表示客户数量,y轴表示处理的RPS数量:

ARM和x86的RPS结果

ARM和x86的RPS结果

当有50、100、150和200个客户端时,ARM的执行速度略慢于x86,这是可以接受的。

我们还测试了响应延迟得到帖子,方法:

GET、POST、PUT的响应延迟

GET、POST、PUT的响应延迟

如果我们把这两组结果结合起来,很明显,当有大约150个客户机时,单个API服务器的瓶颈就会出现。当客户端数量超过150时,即使我们增加更多的客户端,RPS也不会变高,但延迟可能会继续增加。

从这个测试中,我们知道TiDB的性能在ARM和x86之间没有明显的差异。对于我们的应用程序,轻微的差异是可以接受的。

2019年底,我们将数据迁移到TiDB。在迁移之前,在高峰时段,我们通常会有多达6000个慢请求(响应>= 500 ms)。然而,迁移后,同一时间槽位的慢请求数量下降到600以下。换句话说,TiDB将应用程序中缓慢请求的数量减少了10倍。

我们还将TiDB迁移到另一个数据中心。API服务器和TiDB位于不同的数据中心,通过专用连接连接。即使网络延迟增加了1-2毫秒,TiDB仍然改善了整体服务。这不仅仅是令人兴奋的。

ARM-oriented性能调优

我们还针对ARM架构调整了TiDB集群的性能。调弦主要集中在透明HugePages(THP)和NUMA结合。

多亏了PingCAP,我们发现THP对ARM性能有影响。当测试数据量约为100gb时,THP可能会导致TiKV out of memory的情况。因此,我们强烈建议在ARM上禁用THP。

在我们的平台上,ARM有四个NUMA节点。在ARM上,CPU参与内存处理。如果默认情况下没有将CPU核映射到NUMA节点,则NUMA节点越多,延迟越高。因此,为了减少延迟,我们将进程和网络接口卡绑定到相应的NUMA节点上。

TiDB的性能非常好,所以除了在超大数据的情况下,它不需要性能调优。在我们调整了NUMA配置之后,ARM和x86之间的基准测试结果几乎相同:

配置NUMA后,ARM和x86的RPS结果

配置NUMA后,ARM和x86的RPS结果

结论

TiDB帮助U-Next搭建了更稳定、更快的视频流平台,为客户提供优质的服务。它通过其水平可扩展性和惊人的性能解决了传统MySQL架构的痛点。我希望这篇文章能帮助您了解更多关于TiDB的知识,以及如何在ARM上运行TiDB。

准备好开始使用TiDB了吗?