无分片,无ETL:使用扩展MySQL替代存储160+ TB的数据

2021-01-14 58. com 互联网

行业:广告

作者:

  • 刘春雷(58.com高级DBA)
  • 宣凯(58同城前高级DBA)

转接器:Caitin陈编辑:汤姆德万

没有MySQL分片,没有ETL,扩展MySQL替代方案

58. com是中国领先的分类广告在线市场,涵盖各种类别,如就业、房地产、汽车、金融、二手商品和本地服务。商家和消费者可以在我们的在线平台上发布他们的广告,以便他们可以连接、共享信息和开展业务。截至2018年底,我们拥有超过5亿用户,2019年我们的总收入接近22.3亿美元。

随着我们业务的发展,大量的数据涌入了我们的数据库。但独立的MySQL数据库无法存储这么多数据,切分是一种不受欢迎的解决方案。为了实现MySQL的高可用性,我们需要一个外部工具。为了执行联机分析处理(OLAP),我们必须使用复杂而乏味的提取、转换、加载(ETL)作业。我们寻找一个可扩展、易于维护、高可用的数据库来解决这些问题。

经过调查,我们收养了蒂德,一个开源、分布式、混合事务/分析处理(HTAP)数据库。现在,我们的生产环境已经52 TiDB集群那个存储160+ TB的数据,320多台服务器运行在15份申请. 为了维持如此大规模的集群,我们只需要两个dba

在本文中,我们将深入探讨为什么要从MySQL迁移到TiDB,以及如何使用TiDB扩展数据库、执行实时分析和实现高可用性。

我们的痛点

我们将私有云监控数据存储在MySQL中。因为我们的数据量很大,所以我们需要定期清理表。对于我们的dba来说,这是一项繁重的工作。

当我们使用MySQL时,我们遇到了以下问题:

  • 一个独立的MySQL数据库容量有限。它不能存储足够的数据来满足我们的需要。
  • 切分很麻烦。在58同城,我们没有中间件团队,我们的开发人员需要自己操作和维护分片场景。在我们对数据库进行分片后,需要做大量的工作来聚合数据。
  • 要执行OLAP分析,我们必须执行复杂而乏味的ETL任务。ETL过程非常耗时,这阻碍了我们进行实时数据分析的能力。
  • 为了实现高可用性,MySQL依赖于一个外部工具。我们使用Master High Availability(MHA)来实现MySQL的高可用性,但这增加了我们的维护成本。
  • 在主从数据库框架中,MySQL在主从数据库上具有很高的延迟。当我们执行数据描述语言(DDL)操作时,在辅助数据库中发生了高延迟。这极大地影响了实时读取。
  • 一个独立的MySQL数据库不能支持大量的写操作。当我们在一个独立的MySQL数据库中写入数据达到15,000行时,我们遇到了数据库性能瓶颈。

因此,我们寻找具有以下功能的新数据库解决方案:

  • 它有一个活跃的社区。如果它的社区不活跃,当我们发现问题或漏洞时,我们就无法找到解决方案。
  • 它易于操作和维护。
  • 它可以解决我们目前的问题,比如分片带来的问题,大量的写和删除。
  • 适用于多种应用场景,提供多种解决方案。

为什么选择TiDB,一个NewSQL数据库

蒂德一个开源的、云本地的、分布式SQL数据库是由平顶它的开源社区。它兼容MySQL,具有水平可伸缩性、强一致性和高可用性。它是针对在线事务处理(OLTP)和OLAP工作负载的一站式解决方案。您可以了解更多关于TiDB的架构在这里

我们采用了TiDB,因为它满足了我们对数据库的所有要求:

  • TiDB使用分布式存储,可以轻松扩展。我们不再需要担心一台机器的容量是有限的。
  • TiDB是高度可用的。我们不需要使用额外的高可用性服务。因此,TiDB帮助我们消除了额外的操作和维护成本。
  • TiDB支持从多个节点写入数据。这可以防止在向单个节点写入约15,000行数据时出现数据库性能瓶颈。
  • TiDB为分片提供数据聚合解决方案.有了TiDB,我们不再需要分片数据库。
  • TiDB有一个完整的监控系统。我们不需要建立自己的监控软件。

我们如何使用TiDB作为MySQL的替代方案

到目前为止,我们已经部署了52 TiDB集群在生产环境中存储160+ TB的数据,320多台服务器运行在15份申请。我们的数据库日均访问量55亿人次. 为了维持如此大规模的集群,我们只需要两个dba,同时,他们还管理MySQL数据库。

TiDB在58同城的架构

在TiDB集群中,我们的应用程序分离读和写域名,后端使用负载均衡器来平衡读和写负载。默认情况下,单个集群有四个TiDB节点,一个用于写,三个用于读。如果写性能成为瓶颈,我们可以添加TiDB节点。

TiDB的扩展数据库架构在58同城

TiDB在58同城的架构

从TiDB 2.0到TiDB 4.0.2

下表总结了我们多年来如何使用TiDB,以及我们对TiDB的依赖是如何增长的。

日期 TiDB版本 环境
2018年4月 在生产中引入了TiDB 2.0
  • 将监控日志迁移到TiDB
  • 大约每秒2000次
  • 7tb - 8tb的数据
2018年12月 升级至TiDB 2.1 生产中的四个TiDB集群存储我们私有云的所有日志系统数据
2019年9月 在生产和测试环境中升级到TiDB 3.02
  • 存储40 TB数据的80台TiDB物理机器
  • 每日访问量达10亿人次
  • 2300个MySQL集群和11个TiDB集群
  • (我们逐渐从MySQL迁移到TiDB。)
2020年9月 将所有TiDB群集升级到4.0.2
  • 技术与工程集团(TEG)支付管理中心(PMC)订单报表应用程序是我们的核心业务,我们保证不会丢失任何一行数据。它存储了20 TB的数据,每秒有4000次读取查询(QPS)和1000次写入查询。
  • 升级20 TB群集只需9分钟!

我们的应用程序运行在TiDB

我们跑步15个应用程序中的242个TiDB数据库. 举几个例子:

TiDB集群 应用 申请详情 详细资料 议论
三甘醇 WList管理后端和音频配置 WList是由58体系结构平台部门开发的通用分布式密钥列表存储平台 数据大小:63亿行
  • 7.2结核病
  • 在过去6个月中,这些应用程序中有7块闪存卡损坏。但是由于TiDB的高可用性,它们不会影响我们的业务
WTable管理后台 WTable群集应用程序访问监控数据,如机器CPU、I/O和网络 数据大小:262亿行数据
搜索索引 它存储了用户去年使用的搜索词的数据
  • 当前数据大小:3亿行数据
  • 每天增加:50万到80万行数据
安居客(房地产信息服务平台) 操作日志 操作日志 日增:4000万行数据
语句日志 语句日志
  • QPS:高峰时1万
  • 磁盘:1 TB
用户增长 58信息 消息
  • 数据大小:5000万行数据
  • 磁盘:1 TB
信息安全 验证中心 验证中心 每日增加:1百万行数据
金融公司 金融实时数据仓库的底层数据存储 金融实时数据仓库的底层数据存储 数千张桌子

结论

由于TiDB的水平可伸缩性、高可用性和HTAP能力,我们可以告别麻烦的MySQL分片和耗时的ETL。扩展数据库和维护如此大规模的集群非常容易。

现在58同城使用的数据库包括MySQL, Redis, MongoDB, Elasticsearch和TiDB。我们每天的访问量约为8000亿人次。我们有4000多个集群,1500多个物理服务器。

如果您有任何问题或想了解更多有关TiDB的经验,您可以加入Slack上的TiDB社区

准备好开始TiDB了吗?