免费试用

业务挑战

Ninja Van 每天会派送约 150 万个包裹,特别在双 11 和双 12 购物节期间,在极短时间内就会产生成百上千个订单,给平台带来巨大的工作量,其原有数据库面临着巨大挑战:

  • OLTP 工作负载在峰值期间需要进行弹性计算,面对如此庞大的数据量,分片成为 Ninja Van 不得不面临的选择,但是应用层分片需要进行大量的重构;
  • Ninja Van 选择使用 Galera 集群,其本质是一个 MySQL 二进制文件和一个 Glaera 插件。但 Galera 集群操作繁琐,并且不具备扩展性;
  • OLAP 工作负载方面,Ninja Van 选择前端工具 Redash 作为 UI,用来查询副本数据库阵列,却没有针对这种需求的任何数据转换,所有的表设计和数据只是 OLTP 导向的生产数据的简单复制,导致糟糕的性能表现。

解决方案

在综合考虑技术架构的生态系统、社区支持、以及服务本身与 MySQL 的兼容性等因素后,Ninja Van 决定选用兼容 MySQL 并具有高可用性的云原生数据库方案 TiDB 。TiDB 具有丰富的生态系统, TiCDC 可以支持 Ninja Van 的 CDC 需求,并且有工具使 Ninja Van 数据从 MySQL 同步到 TiDB, 甚至从 TiDB 同步到其他数据库,保证迁移顺利完成。目前, Ninja Van 每个月都会进行一项迁移服务,稳中有进,现在已经有十几个数据库转移到 TiDB 。

迁移计划

Ninja Van 在 Kubernetes 集群上有一个运行的应用,这个应用对应一个运行在虚拟机上的 MySQL 实例。应用程序最初连接到 MySQL,Ninja Van 首先在 Kubernetes 中部署 TiDB,然后使用由 PingCAP 提供的 DM / TiDB Lightning 工具,将数据从 MySQL 同步到 TiDB,在数据迁移完成后,应用程序将连接到 TiDB,最后 TiDB 使用 TiCDC 将数据再次同步回 MySQL 。

kubernetes.png

在这个过程中,TiCDC 扮演着三个重要的角色:

第一,先同步到 MySQL 副本,并由 Maxwell 订阅,然后发布到 Kafka, 供数据湖使用;

第二, TiCDC 会直接发布 Maxwell 格式消息,这些消息会被其他消费者接受,比如同步数据到 Elasticsearch 的消费者;

第三, TiCDC 发布多源副本到 TiDB。

TiCDC.png

业务收益

  • Ninja Van 所有应用程序都基于 MySQL,TiDB 完美兼容 MySQL,使得整个迁移过程十分便捷,无需进行业务改造;
  • TiDB 具备读写可扩展性,可以应对业务的快速增长;
  • TiDB 具有高可用性,即使集群出现部分故障,依然可以正常工作;
  • 可以通过 CDC 将数据变更发布到其他系统,如数据湖和 Elasticsearch 进行监测;
  • TiDB 支持 Kubernetes 原生部署,保障 Ninja Van 的所有工作负载都在 Kubernetes 上良好运行。
Ninja Van
客户简介

行业:物流

Ninja Van(能者物流)成立于 2014 年,是东南亚地区最后一公里派送的物流公司。总部位于新加坡,经过多年在东南亚业务的扩展,现在的服务网络已经在六个国家(新加坡、马来西亚、菲律宾、印度尼西亚、泰国和越南)实现了 100% 覆盖率。

咨询案例详情

体验全新的一栈式实时 HTAP 数据库

新经济行业内容专区上线,为新经济企业数据库选型和应用提供深入洞察和可靠参考路径。