一个顶级汽车交易平台选择一个扩展数据库作为MySQL的替代

2021-01-12 Chehaoduo 互联网

工业:汽车

作者:葛凯文、韩建生、王射阳(车豪多TiDB虚拟团队)

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

车好多使用一个扩展的MySQL替代数据库

Chehaoduo是一个新车和个人二手车的在线交易平台。该公司成立于2015年,目前是中国最大的汽车交易平台之一,在去年的D轮融资中估值为90亿美元。

在车好多的早期,为了快速适应我们的应用开发,我们选择了MySQL作为我们的主要数据库。然而,随着业务的发展,我们被MySQL分片和模式变化的复杂性所困扰。面对这种困境,我们找到了一个替代MySQL的数据库:TiDB这是一个与MySQL兼容的开源数据库,可以向外扩展以容纳大量数据。

在这篇文章中,我将与你分享我们为什么选择TiDB,以及它如何使我们的应用程序为我们的客户提供更好的服务。

MySQL的不足之处

MySQL是一个不提供横向可伸缩性的独立数据库。当我们的数据量超过某个阈值后,MySQL就不能再提供令人满意的性能了。

单个MySQL实例有限制

随着数据的积累,单个实例经常会达到每秒查询(QPS)限制并耗尽存储容量。为了将数据压缩到单个实例中,我们必须将大表拆分为小表,并拆分更改数据捕获(CDC)层和数据仓库(DW)层。

无论何时我们必须分割表,应用程序团队都必须与CDC团队和DW团队一起工作。如果有问题的应用程序与其他应用程序共享数据库或表,则负责其他应用程序的人员也必须参与这个过程。此外,在迁移过程中可能会忽略小型脚本程序,这可能会影响应用程序数据。

根据应用程序的数据量,每次拆分可能需要2到4周时间。这是在浪费时间和精力。

MySQL分片对应用程序是侵扰性的

随着用户群的增长,一些表可能会有数千万条数据记录,这会降低读写速度。通常的方法是对数据进行分片,但这有一些问题:

  • 分布式事务很难处理。
  • MySQL无法创建二级索引。
  • 碎片可能无法进一步扩展。
  • 没有办法执行跨分片连接。
  • 很难对结果集执行排序合并连接。

为大表更改模式是很困难的

在车豪多,我们的商业模式变化很快。为了适应业务需求,我们必须经常更改表模式。

当一个表有数百万条记录时,我们需要一个第三方工具来执行数据定义语言(DDL)命令,例如pt-online-schema-change(pt-osc)。在模式更改过程中,我们必须创建表的临时副本,然后应用更改。这很耗时,可能会影响存储、I/O和应用程序。

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

为了解决这些痛点,我们考虑改革和升级现有的数据库体系结构。我们从应用程序方面分析了需求,并将它们与一些常见的数据库解决方案进行了比较。

比较各种解决方案

解决方案 优势 缺点
MySQL分片
  • 很容易根据ID进行查询。
  • 在短期内,实施成本很低。
  • 随着表的线性增长,维护变得越来越困难。如果每个表包含数百万行数据,那么每年至少要添加30个新表。
  • 数据分片需要修改代码。
  • 如果我们引入了分片中间件,我们需要雇佣新的员工来维护中间件。
MongoDB
  • 成熟的技术。
  • 当数据量较大时,可以通过分片向外扩展。
  • 我们需要重构整个应用程序,这在短时间内是不可能的。
  • 它是一个文档数据库,因此应用程序需要构建自己的数据验证逻辑。
Elasticsearch (ES)
  • 强大的搜索能力(通过二级索引)。
  • 当遇到大量的更新时,ES可能会有较高的延迟。同时,它也会经历容量的增加和段数的增加,从而触发合并,从而影响搜索性能。
  • 无模式。长期维护是昂贵的。
HBase
  • 成熟的技术。
  • 基于rowkey的查询,没有额外的工作负载。
  • 它水平扩展。
  • 当rowkey无法查询数据时,需要特殊的开发。它的接口不是通用的。
  • 不支持二级索引。
  • 该协议与我们当前的读写程序不兼容。
HBase +凤凰
  • 底层采用HBase作为KV存储。强大的稳定性。
  • 规模水平。
  • SQL语法不是通用的。它只有“upsert”,没有“insert”或“update”。
  • Phoenix依赖Percolator来实现事务,但这可能不可靠。
HBase +西文
  • 使用HBase作为OLTP存储,ES作为二级索引。
  • 利用两者的优势。
  • 不支持事务。
  • HBase和ES之间很难保持数据一致。
TiDB
  • 它与MySQL协议完全兼容,几乎不需要对应用程序进行任何更改。
  • 分布式存储、无限的可伸缩性和高可用性。
  • 一个完美的替代MySQL分片。
  • DDL模式更改不会影响应用程序。
  • 具有快照隔离级别的事务支持。
  • 与疾控中心兼容。
  • 它需要高端的硬件资源。
  • 没有触发器。没有存储过程。与某些语法不兼容。

综上所述,TiDB是水平扩展和MySQL兼容的。它支持在线DDL模式更改和分布式事务。这些特性结合起来适合车豪多的用例:大数据量、频繁的模式更改和长期的数据存储。

分析我们的使用场景

在研究了TiDB的优势之后,我们还分析了车豪多的具体使用场景,总结了应用方的关注点:

  • 一个应用程序有近3亿行数据,每天新增170万行,每月新增5000万行。即使MySQL中只存储2个月内的热点数据,单个表也可能会被超过1亿行数据填满。
  • 汽车的销售周期比其他产品长。在漫长的销售周期中,一度低迷的数据可能会再次升温。因此,应用程序可能需要更新冷数据。由于应用程序为在线用户服务,数据库需要实时读写。
  • 多个应用程序可以从相同的数据集读取数据,每个数据集具有不同的查询条件。
  • 当数据发生变化时,应用程序需要相应的逻辑来处理这些变化。数据库必须提供CDC数据流,以便应用程序可以监视数据更改。

基于这些要求。我们决定将几个应用程序迁移到TiDB,包括机票分发和转帐、电话销售系统、业务中心中心和会计系统。这些应用程序积累了大量的数据。其中一些必须经常添加新字段,而另一些则需要事务。TiDB当然可以帮助他们。

我们的迁移过程

面对一个新的数据库,核心应用团队不禁对它的稳定性和可靠性感到担忧。为了增强他们的信心,我们决定在一些不太重要的服务上试行该系统。整个测试过程分为三个阶段。

第一阶段是使用TiDB作为MySQL复制集群并使用TiDB数据迁移(DM)。应用方检查TiDB的数据一致性、稳定性和性能是否满足他们的要求。之后,我们将一小部分在线请求路由到TiDB并观察数据。随着一切进展顺利,我们逐渐增加了比例,直到TiDB完全接管了所有的读请求。数据验证没有失败。那时,应用方对TiDB有了信心,准备进入下一个阶段。

迁移阶段1

迁移的第一阶段:使用TiDB作为副本集群

在第二阶段,应用程序在没有DM的情况下同时写入MySQL和TiDB,直接从TiDB读取并写入TiDB。我们仍然将数据单独写入MySQL,以备不时之需。这个阶段持续了两个季度,期间TiDB正常运行,并通过了我们每天的数据验证。

迁移阶段2

迁移的第二阶段:同时写入MySQL和TiDB

到最后阶段,TiDB已经赢得了我们的完全信任。我们把MySQL放到一边,把TiDB作为一个独立的数据库放到我们的生产环境中。

迁移阶段3

迁移的最后一个阶段:在生产中使用TiDB作为独立的数据库

有了TiDB,我们的服务质量有了很大的提高:

  • 应用程序可以查询的时间范围已经从最近三个月扩展到所有历史数据。
  • 即使有近10亿条数据记录和1000个QPS,我们99.9个百分点的延迟仍然低于128毫秒。

经验教训

在生产环境中运行TiDB时,我们遇到了一些问题。在这里,我想分享一些我们的经验教训。

选择正确的版本

对于生产环境,我们建议选择一个正常运行了一段时间的版本。

TiDB是一项持续发展的技术。Bug修复和新特性不断地添加到新版本中。自从我们第一次研究以来,TiDB已经从2.0版成熟到4.0版。当我们从v2.1升级时。3.0 x。x时,我们没有注意到SQL模式的变化,这导致了由ONLY_FULL_GROUP_BY规则。现在,我们只选择稳定的版本,并且通常不升级我们的集群,除非我们遇到了关键的bug或者需要新的特性。

绑定您的SQL

因为TiDB使用基于成本的优化,当统计信息发生变化时,优化器可能会选择一个错误的索引。有一次,我们看到整个CPU利用率,I/O的上升,以及系统中大量的查询超时。我们商议后PingCAP, TiDB背后的团队,我们通过SQL绑定

孤立的资源

随着我们对TiDB越来越有信心,我们希望将更多的应用程序迁移到它。然而,由于硬件资源有限,我们无法立即让几个独立的TiDB集群上线。因此,我们的DBA团队探索了在同一组物理服务器上部署多个集群的可能性。

为了实现混合部署,我们必须将资源彼此隔离。TiDB有三个关键组成部分:PD(调度程序),TiKV(存储)TiDB(计算层)。

  • PD资源需求低。
  • TiKV支持在软件层配置最大CPU和内存。我们还在同一台机器上挂载多个ssd,以隔离I/O。
  • TiDB还支持在软件层限制CPU和内存使用,但它不能在短时间内停止快速增长的内存访问。幸运的是,我们可以进行配置memory_limit在systemd和let中并且限制内存使用。这也激励我们尝试使用Kubernetes和Docker来完全控制资源。

在我们验证了一个集群上的异常SQL语句不会影响同一物理机器上的其他集群后,我们用TiDB逐个连接其他应用程序。

我们与TiDB的未来计划

我们目前的基础设施与TiDB紧密相连,我们仍希望通过它取得更多成就。

部署在云上

TiDB是一个云本地分布式数据库。我们现有的集群大多部署在本地。未来,我们计划将TiDB部署到云上。与TiDB运营商Kubernetes运营商的TiDB, TiDB将能够自动分配资源,提高资源利用率。这将大大节省维护费用。

探索TiKV

我们的广告应用程序对服务延迟很敏感。它提供基于用户数据的定向广告。随着我们的数据在过去五年的积累,我们需要一个可持久化的键值存储来为广告应用程序提供服务。

TiKVTiDB的存储组件引起了我们的注意。TiKV最初是为了补充TiDB而创建的,但我们也可以独立于TiDB部署它作为低延迟、持久存储。我们已经实施了这个项目,并计划将TiKV的使用扩展到更多的应用。

应用TiCDC

在迁移到TiDB之前,我们基于MySQL二进制日志构建了我们的数据流服务。现在TiDB作为我们的主数据库运行,我们使用Pump和Drainer来复制binlog。

TiDB 4.0引入了一个新特性,TiCDC,它更容易部署,并支持多种格式的输出。我们会逐步将TiCDC纳入我们现有的系统。

与内部平台集成

在车豪多,我们的DBA团队开发并维护了一个MySQL管理的内部平台。dba和开发人员都可以在这个平台上执行日常例程。为了统一系统,我们将TiDB整合到平台中,实现自动化运维。

简化迁移过程

目前,我们的迁移过程有两个主要部分:使用DM迁移数据,然后迁移应用程序。我们希望使应用程序端的迁移更容易,例如,通过在体系结构中引入SQL代理。应用程序将只连接到代理层,而不关心后端是MySQL还是TiDB。

我们与TiDB的未来计划

我们与TiDB的未来计划

如果没有TiDB,上述计划将无法实现。将TiDB作为我们架构中的核心组件之一,我们将构建一个强大的系统来支持我们的长期业务。

准备好开始使用TiDB了吗?