跨境电商如何通过打好数据底座，实现低成本稳步增长

今天我们邀请了 OceanBase 资深解决方案架构师孟磊围绕“原生分布式数据库助力跨境电商低成本稳步增长”为大家展开分享，结合实践与案例，探讨跨境电商如何通过打好数据底座，保障未来业务稳步增长的同时，用更低的成本享受更高的性能。

资深解决方案架构师

孟磊 | 花名：亦年

毕业于湖南大学，多年海外工作经验，曾在 Oracle 从事多年数据库售后及解决方案工作，加入 OceanBase 后负责大型金融、政企、互联网等多个行业头部客户的分布式系统改造项目。

以下是正文内容：

“大航海”时代来临。目前，围绕跨境电商已经形成了第三方平台/独立站商家、跨境 SaaS、跨境仓储物流、跨境支付等相对比较完整的生态链。借助中国强大的供应链能力，我们可以将更多物美价廉的中国产品远销海外。

与此同时，跨境电商也迎来了新的时代。新时代下的跨境电商主要会有以下三大转变：

• 一是从中国产品向国际品牌转变。越来越多的中国产品开始构造自己的护城河，逐步在国际市场上建立起影响力。

  
  

• 二是从单平台运营向多平台运营、独立站转变。去年的“亚马逊事件”后，很多跨境商家看到了多平台甚至独立站的必要性。

  
  

• 三是从粗放式经营向精细化经营管理转变。具体在数据库层面，我们看到实时计算分析、多云数据融合的需求越来越多。

不同阶段跨境电商，

典型关系型数据库选择

我们先来看这样一条增长曲线，跨境电商的不同成长阶段大致可以划分为初创期、高增长期、成熟期，不同成长阶段选择数据库都有不同的侧重。

初创期的跨境电商，要更加考虑成本问题，大多会选择规格较小、较灵活的开源数据库，如 MySQL，去支撑前期在一定规模范围内的业务发展。为了节省成本，大多也会选择部署在公有云之上。

但随着业务和数据的增长，MySQL 通常会遇到性能或架构瓶颈。这时候就会切换至性能和扩展性较强的云原生分布式数据库。

随着业务规模的进一步增长，大型的跨境电商会构建自己的数据中心。同时，为满足多样化的数据需求，数据库的类型不断增多，如 OLTP 使用数据库 A、OLAP 使用数据库 B、财务分析数据部署在国内的阿里云、经营管理分析数据部署在国外的 AWS 等。

虽然这种多数据库、多云的部署形态也能支撑跨境电商的业务发展，但由于不同云上的数据库特性不一样，将会面临着大量数据库堆栈的复杂管理、数据跨库/跨云同步链路问题，以及最重要的成本问题，包括数据库使用成本、运维成本等。

跨境电商选择数据库的 6 大关注点

数据库是保障跨境电商稳步增长的核心底座。为了更好地帮助跨境电商，我们在服务众多跨境电商的过程中，总结出跨境电商选择数据库的 6 大关注点，供正在选型、升级数据库的跨境电商参考。

关注点 1：性能及稳定性

数据库的性能及稳定性，可以说是我们选择数据库时需要重点关注的“1”，如果没有这个“1”，后面有再多的“0”都没有用。

如果核心交易链路出现瓶颈，将会影响整个交易核心的处理能力，导致架构性能难以突破瓶颈。基于传统 MySQL 数据库，当业务量变大、数据量激增时，会遇到各类性能问题，如大数据量下的查询、复杂多表关联等，还有运维方面的在线表变更、主备延迟等。

关注点 2：平滑扩缩容

跨境电商经常会面临一些大促活动和商品秒杀等场景，这些场景会面对脉冲式流量，希望能具备在最短的时间付出最小的成本来应对。

如果只能通过 scale-up 或者增加只读节点，只能解决部分问题，而选择具备平滑扩缩容能力的数据库，可以一键式线性平滑扩展，不存在数据量或负载天花板。跨境电商就能用尽可能低的扩容成本，承载尽可能高的业务压力和数据量。

关注点 3：HTAP 能力

随着流量、商品 SKU 增加，跨境电商对精细化运营的要求、实时智能推荐等对分析时效性的要求越来越高。

传统数据库想要实现 HTAP 能力，通常会基于主备库做一些读写分离的拆分、或者通过中间件进行分库分表等实现。选择具有 HTAP 能力的数据库，在一套数据库中实现 TP 和 AP，将能极大地缩短数据链路、减少数据冗余，提高数据分析的时效性。

关注点 4：多云能力

随着出海地区的增多，很多跨境电商会选择进行多平台的运营，或者独立建站，通常会涉及到多朵云，包括自建 IDC。

多云厂商供应的情况下，很多跨境电商希望技术堆栈可以保持云中立，这就需要选择具有多云能力的数据库，包括实现不同云之间的数据同步或容灾等。

关注点 5：成本

成本永远是大家都非常关注的一个点。随着业务增长、数据库数量增长，海量数据带来的存储成本攀升，包括数据库的管理运维成本。跨境电商需要选择适应数字化时代的数据库，能削减数据库的使用、运维等成本的同时，享受更高的性能。

关注点 6：合规

跨境电商业务快速发展的过程中，安全建设往往容易被忽视。软件合规要求、当地数据合规要求，如欧盟的《通用数据保护条例》（简称 GDPR）、美国的《金融服务现代化法案》（简称 GLBA）等，跨境电商在选择数据库时需要纳入考虑范围内。

不同场景下的数据库能力选择

大家其实基本都已经是 OceanBase 的用户。比如说在淘宝收藏一件商品，或者在支付宝进行支付转账、将钱存入余额宝等，这背后都是 OceanBase 数据库在做底层支撑。

支付宝从 2013 年开始出海，目前覆盖超过 200 多个国家和地区。现在，支付宝可以不到 4 小时完成海外站点的技术建站，底层就是基于统一标准的技术堆栈。跟随蚂蚁集团的出海战略，OceanBase 也由此打磨出跨境场景下的核心竞争力。

今天我不会给大家介绍非常技术的知识，而是会从跨境电商的重点场景出发，重点介绍 OceanBase 在这些场景下具备的能力，以及能为跨境电商带来的价值。

电商大促场景

在“黑色星期五”或业务快速增长的高并发场景下，跨境电商首先需要考虑的是性能与稳定性。高峰期任何抖动对用户都会产生很大的影响。OceanBase 连续 9 年稳定支持“双 11”，性能与稳定性已经在蚂蚁集团内部经过多年打磨。

此外，OceanBase 提供平滑扩缩容的能力，可以做到小时级别一键式从日常模式扩展至大促模式，大促后一键缩容，对业务完全透明，业务全程在线。

像我们会在“双 11”开始之前，将自建机房的 OceanBase 集群弹出至阿里云的公有云上，承担每年的大促。大促峰值后可以将资源快速释放。

OceanBase 作为企业级原生分布式数据库，没有集群、机器数量上限，跨境电商可以不断地纵向或横向扩展集群，增加系统处理能力。

在热点商品的秒杀场景下，扣减处理并发越高，行锁竞争越激烈，从而会影响性能和整个集群的吞吐。OceanBase 具备提前解行锁特性，在该场景下可最大限度增加吞吐能力。

T+0 混合负载场景

OceanBase 是全球唯一在 TPC-C 和 TPC-H 测试上都刷新了世界纪录的国产原生分布式数据库，支持一份数据进行事务处理的同时进行实时分析处理。

很多跨境电商在解决混合事务处理和分析处理的问题时，会选择从 MySQL 数据库搭一条数据链路至另一个 OLAP 数据库进行分析处理。OceanBase 可以通过一套集群完成 OLTP 和 OLAP 的混合负载，缩短数据链路，有效减少数据冗余。

进行分析处理时不影响业务交易，也是跨境电商的普遍诉求，这底层其实是业务隔离的问题。OceanBase 有多种解决该问题的方式，如用一个单独的副本承载 OLAP，或者在同一个数据库中进行 OLTP 和 OLAP 处理的资源隔离，保证处理时互相不受干扰。

多云部署场景

OceanBase 并不依赖于任何云底座，或者任何硬件设施，支持多种公有云、私有云、混合云统一的产品服务能力、支持应用快速迁移部署和跨云协同。

公有云和私有云提供完全一致的产品功能、接口、开放能力与体验，OceanBase 将私有部署与公有云通过安全网络设施相互联通，若跨境电商的单一服务遇到负载压力、故障与灾难，能够快速将负载切换到其它云服务。

数据库整合场景

数据库整合适用于数据库实例相对较多，以及类似跨境 SaaS 这类同时对多租户和隔离有要求的场景。

第一，多租户架构。OceanBase 集群提供一个统一的资源池，根据需要可以创建多个数据库的租户，每个租户相当于一个 MySQL 实例。所以说，OceanBase 的一套集群，就可以整合几十、上百套 MySQL 实例。有效解决大量单实例与日俱增、软件授权费用节节攀升、运维成本高居不下的问题。

第二，多租户资源隔离。OceanBase 每租户之间物理隔离，可动态调配租户之间的资源。跨境电商若遇到实例使用率低，不能很好地统一调度管理、合理利用资源，存在严重资源碎片的问题时。通过 OceanBase 能有效提升资源的利用率，同时减少运维成本。DBA 只需管理少数集群，即可支撑多套业务。

跨境 SaaS 企业对多租户应该深有感触，因为既有将多个小商家的数据放在同一套 MySQL 的场景，也有将一些大商家的数据单独放在另一套 MySQL 的场景。这种情况只需在 OceanBase 建租户即可解决，如果某个商家业务增长较快，OceanBase 可以动态调整资源。

第三，高级数据压缩技术。OceanBase 基于 LSM-Tree 算法自研存储引擎，采用数据编码与压缩算法，实现高压缩比。从 MySQL 迁移至 OceanBase，最少可以减少 60% 的存储容量，即 100TB 数据迁移至 OceanBase 可能只有 40TB，这将大幅降低跨境电商的计算和存储的成本。

数据安全场景

现在很多跨境电商都非常关心数据安全的问题，如 GDPR 等。每家云厂商都有自身的安全体系，例如 ISO 或 SOC。数据库层面，OceanBase 提供端到端的数据安全，安全体系包括身份鉴别和认证、访问控制、数据加密（TDE）、监控告警、安全审计，各层组件均支持 SSL/TLS 加密通信，为业务提供安全的加密传输服务。

OceanBase 数据库还兼容 Oracle 的 Label Security 功能，可在行级别对访问进行控制，保证读写数据的安全，并提供数据库审计能力，可分别对用户、数据库对象或者具体操作进行审计，审计记录可选择存放在表中或者操作系统文件内。

数据一站式迁移场景

OceanBase 提供 OMA（OceanBase Migration Assessment，OceanBase 迁移评估）和 OMS（OceanBase Migration Service，OceanBase 数据迁移服务）工具，帮助跨境电商先进行整体评估后一站式迁移数据。

OMA 将为跨境电商提供全面的数据库画像，掌握数据库拓扑、应用拓扑、整体负载和兼容性分析报告，为数据库的迁移策略提供决策支撑。

在数据库迁移上，OceanBase 有自己独特的优势。例如：

• 多表合一迁移能力。如果原有的数据库已经进行分库分表，OceanBase 支持多表合一的迁移，将原有分库分表架构整合至一套集群。

  
  

• 白屏化的数据校验能力。OceanBase 可以对源端和目标端进行数据校验，如果检测到不一致会自动生成订正脚本。

  
  

• 数据链路的回切能力。如果从数据库 A 迁移至 OceanBase，OceanBase 会从数据库 A 的备库开始挖增量数据，当增量数据追平后在非常短的时间窗口内将应用切换至 OceanBase，应用无需做任何代码修改。同时，OceanBase 还支持链路回切，从 OceanBase 反向写回数据库 A。

OceanBase 跨境电商客户案例

某跨境快时尚品牌，实现透明可扩展

得益于物美价廉，该跨境快时尚品牌（以下简称“该品牌）在疫情期间的业务增长非常快，一度超越 H&M、Zara 等老牌快时尚品牌的销售额，成为欧美最受欢迎的快时尚品牌之一。

该品牌以独立站为主要销售阵地，过去采用全 IaaS 层自建 MySQL 数据库。随着业务量、数据量的猛增，MySQL 的单个实例扩容已达瓶颈，无法垂直扩展，数据库抖动严重。于是该品牌开始进行分库分表的改造，但发现改造时间成本不可控、应用影响过大，近千套 MySQL 实例带来与日俱增的运维成本。

经过多方严格考核，该品牌最终选择 OceanBase 帮助其解决自建 MySQL 扩展性差、可维护性差等难题。通过 OceanBase 透明可扩展的能力，无需业务分库分表，通过横向增加节点即可实现线性的业务性能扩展，为后续站点的快速增长提供弹性伸缩能力。

迁移至 OceanBase 后，凭借 OceanBase 的高压缩技术，存储成本下降了约 80%。以该品牌的 DMS 业务存储大小为例，通过 MySQL 存储高达近 1.5T，而 OceanBase 仅为 200 余 G。每增加一组节点，写性能扩展、读性能扩展也得到了翻倍的提升。

致欧家居，实现多云部署

致欧家居目前已经成为亚马逊欧洲第一大家居卖家，2021 年营收近 80 亿，年度同比增长近 100%。致欧家居的业务平台分布全球，云端部署结构相对复杂，不仅有欧洲、北美的 AWS，中国的 IDC，还有中国香港的阿里云等。其在升级数据库时，主要有两个诉求：

• 一是实现多云之间的数据同步，如将 AWS 上的数据，通过过滤和计算，同步至中国香港的阿里云上，然后去做一些分析和决策。

  
  

• 二是是希望自己的运维团队有能力可以使用不同云上的不同功能的数据库，统一数据堆栈，让 DBA 对数据库整体有更强的掌控力。

如下图所示，OceanBase 为致欧家居提供了多云部署的解决方案。通过 OceanBase，致欧家居不仅实现了数据库多云部署及技术栈收敛，还实现了基于一个技术栈对数据进行融合汇聚，并且代码零改造。