在互联网与电商爆发增长的时代,物流企业的竞争不仅在速度与覆盖率,也在于数据驱动的运营效率和实时决策能力。成立于 2014 年、覆盖东南亚六国的 Ninja Van 以其最后一公里配送能力为电商生态提供关键支持。随着订单量与业务复杂度指数级增长,传统数据库架构逐渐成为制约企业扩张与业务创新的瓶颈。面对每日数百万次配送与海量并发查询,Ninja Van 选择了分布式 SQL 数据库 TiDB,完成从分析型数据仓库到核心事务系统的双向迁移,从而实现实时运营智能与可观的运维降本增效。 在早期,Ninja Van 使用 MySQL 与 Galera 集群做为主力数据库。Galera 提供的多主复制曾有效支撑初期业务,但随着规模增长,写密集型操作逐渐压垮了集群节点。
高并发下的流控与复制延迟问题频出,新增节点还会触发状态快照转移,带来严重的性能抖动。为缓解压力,团队引入 ProxySQL 做流量分发和读写路由,但这把复杂性向应用层转移,分片逻辑难以维护,运营成本与技术债呈几何级增长。为了支持分析团队的复杂查询,团队不得不维持数百个 MySQL 实例,资源利用极不均衡,人力成本也不断攀升。 更令人头疼的是,业务对实时数据的需求超过了传统复制架构的能力边界。Ninja Van 的平台需要支撑实时包裹追踪、用户通知、仓储优化以及风控与反欺诈等场景。业务团队常常编写数百行的 SQL 来构建仪表盘、做临时分析或排查问题,期望实时或近实时的数据。
MySQL 的只读副本在面对复杂聚合和模糊查询时频繁超时或失败,复制延迟导致数据陈旧,扩容成了简单粗暴但成本极高的应对方式。最终,系统演进成一个四层的复制与代理迷宫,虽然具备一定的容错能力,但无法长久支撑业务迭代。 正是在这样的背景下,Ninja Van 开始评估分布式 SQL 方案。关键需求包括对 MySQL 的兼容性以避免海量查询改造、对读写的水平扩展能力、原生支持 OLTP 与 OLAP 的混合负载、变更数据捕获(CDC)以供下游数据湖与实时管道使用、以及对 Kubernetes 的原生支持来简化运维。经过对 Vitess、CockroachDB、阿里云 ADB 等方案的测试,TiDB 因其 MySQL 协议兼容、HTAP 能力和成熟的运维生态脱颖而出。 Ninja Van 并未立即将核心交易系统切换到 TiDB,而是采用了渐进式策略,从运营数据仓库 Operational Data Store(ODS)开始试点。
这一选择既谨慎又富有战略意义。ODS 在数据架构中承担分析与复杂查询的职能,对延迟的敏感度低于面向用户的交易系统,且原本的重读与聚合压力最适合用来验证 TiDB 的 HTAP 能力。通过将分析型负载迁移到 TiDB,团队可以观测 TiDB 在高并发多用户场景下的表现,并在不影响核心服务的前提下积累运维经验。 在 ODS 的部署中,Ninja Van 将 TiDB Data Migration(DM)用于与现有 MySQL 数据源的同步,采用共享的 TiDB 集群为多个区域提供服务,通过资源隔离策略避免噪声邻居问题,并引入列式存储节点以加速分析查询、减轻事务层压力。此外,基于角色的访问控制保障了超过一万名 Redash 用户的安全自助分析能力。迁移之后,曾经需要分钟甚至失败的复杂查询在 TiDB 上能在数秒内返回,实时洞察能力显著提升。
在成功把 ODS 打造成验证场景后,Ninja Van 将迁移目标扩展到事务负载,这是对分布式数据库能力的真正考验。事务系统涉及实时配送、订单管理、第三方电商接口和包裹追踪等关键路径,任何中断都可能直接影响用户体验和合作伙伴关系。更复杂的是,超过 180 个微服务依赖 MySQL 后端,许多服务有严格的低延迟 SLA,迁移必须平滑、逐步且不改变大量现有查询。 TiDB 在交易场景中的价值在多方面体现。其对 MySQL 协议的高度兼容使得服务可以逐个迁移,而无需对数万条 SQL 进行重写。在线模式的模式变更支持消除了以前依赖 gh-ost 等工具的繁琐操作,DDL 执行不再成为线上风险点。
内置的变更数据捕获 TiCDC 能够无缝地把数据库变化分发到数据湖、Kafka 管道和实时仪表盘,确保下游系统的同步与一致性。备份与恢复、基于 TTL 的归档机制也变得更为稳定和可审计,摆脱了此前靠脚本拼凑的风险。 性能方面,TiDB 在 Ninja Van 的生产环境已经证明其可承载极高的负载。系统峰值查询吞吐量达到每秒 44,000 QPS,同时支撑十万级别的查询并发和成千上万条复杂分析查询。更关键的是,平台规模达 130TB 以上的数据,仍由极小的运维团队高效管理。事实上,覆盖上百 TB 数据并为数百万次配送提供服务的 TiDB 集群,仅由一个两人平台团队负责日常运维、升级和故障处置,这种运维杠杆的提升在业务快速扩展时带来了决定性优势。
技术栈现代化也是 Ninja Van 赢得规模化交付能力的重要一环。过去团队依赖大量 shell 脚本、Ansible Playbooks 与人工干预来部署与升级数据库。采用 TiDB 之后,整个运维流程实现了 IaC 化,使用 Terraform、Terragrunt 与 Kubernetes 清晰地定义集群资源与生命周期。CI/CD 管道用于管理版本、补丁和集群制品的发布,任何 TiDB 升级都会先在 ODS 环境进行回归验证,确保上线的稳定性。监控体系与可观测性也得到加强,与 Grafana、Prometheus 的集成让性能瓶颈更容易被发现和定位,告警策略帮助平台在异常发生前或发生初期进行干预。 Ninja Van 的实践展示了一个关键的组织与技术协同效应。
数据库层面的可靠性与扩展性解放了开发团队,让他们不必再为运维细节耗费大量时间,从而有更多精力投入到业务模型与客户体验的优化上。TiDB 的 HTAP 能力使得分析与事务共存成为可能,数据团队不再需要为 OLAP 专门搭建大量只读副本或复杂的 ETL 管道,实时分析几乎成为默认功能,这对快速迭代与运营决策至关重要。 尽管已经取得显著成果,Ninja Van 仍在持续演进他们的架构与运营模式。下一阶段的重点包含向基于 ARM 的集群迁移以追求更高的性能成本比,改进迁移工具以加速剩余 MySQL 负载的平滑切换,进一步精细化资源控制策略以在不同业务部门与区域之间分配性能优先级,以及将数据规模扩展到 200TB 甚至更大以应对每天递增的 200GB 数据量。 Ninja Van 的案例对其他希望以数据能力驱动业务增长的企业具有多重启示。首先,渐进式迁移策略可以显著降低风险,从非核心但重要的 ODS 开始验证技术并积累经验是可复制的路径。
其次,对 MySQL 协议兼容性的重视极大地降低了迁移门槛和成本,使得服务可以按单元迁移而非一次性重写整体系统。再次,HTAP 架构可以同时满足事务与分析需求,减少数据孤岛与复杂的 ETL 维护工作。最后,现代化的运维实践与 IaC 能把运维复杂度转化为可重复的工程流程,从而以更少的人力管理更多的数据与请求量。 对于希望实现类似转型的企业,有若干工程和组织层面的建议值得参考。评估数据库时要把 MySQL 兼容性、在线 DDL、变更数据捕获和 Kubernetes 原生支持列为核心考量。迁移策略应包含分阶段的验证路径,优先级从低风险但高价值的分析场景开始,再逐步覆盖高敏感度的事务系统。
构建可靠的 CI/CD 和监控体系是保障升级与扩容安全的关键。最后,运维团队的能力建设不可忽视,少量高效的工程人员借助自动化工具能达成大规模运行的目标,但前提是清晰的运行手册和故障演练机制。 Ninja Van 用 TiDB 打造的运营智能平台证明,在规模化的物流场景中,技术选型可以既满足高并发事务又提供实时分析能力,而不必在两者之间做出牺牲。通过逐步迁移、工具化运维和资源隔离策略,企业能够在保证业务连续性的同时显著提升数据可用性与开发效率。随着数据规模不断增长,面向未来的架构设计与生态建设将决定企业在竞争激烈的市场中能否持续保持敏捷与成本效益。 面对日益复杂的供应链与用户期望,实时洞察和高可用事务处理已经从竞争优势变成了运营必需。
Ninja Van 的实践为物流及其他需要高并发与实时分析的行业提供了一个可行路径。借助 TiDB 的分布式 SQL 能力,企业可以把分片与复制的复杂性从应用层抽象出来,在保障兼容性的前提下,以更低的人力成本和更高的稳定性,构建可以横向扩展、支持 HTAP 的现代数据平台。未来在 ARM 芯片优化、资源控制策略和更完善的迁移工具加持下,这样的平台还将进一步提升性能和性价比,支持业务以更快速度扩展客户与服务边界。 。
