AI 年度盘点与2025发展趋势展望,50+案例解析亮相AICon 了解详情
写点什么

独家揭秘东南亚电商平台 Prestomall 去 Oracle 的全过程

  • 2020-02-12
  • 本文字数:3180 字

    阅读完需:约 10 分钟

独家揭秘东南亚电商平台 Prestomall 去 Oracle 的全过程

很多人都说:“现在的东南亚就像是坐着时光机,回到了 90 年代的中国市场。” 的确,在互联网领域,我们经常能在东南亚看到中国互联网发展历程的影子。本文我们将详细介绍一下东南亚企业的去 Oracle 经历,揭秘中国经验是如何复制到东南亚市场的。


Prestomall 是一家成立于 2014 年的东南亚电商企业,此前这家企业一直使用的是 Oracle 数据库。所有业务全部由一套 Oracle 数据库支持,同时还有一套 Oracle 数据库用来支撑测试环境。


2018 年 8 月,距离 Oracle 数据库软件授权证到期还有 3 个月的时间,Prestomall 决定不再使用 Oracle 数据库,并开始寻找替代方案。为什么 Prestomall 决定在这个时候去 Oracle 呢?选定的替代方案是什么呢?整个迁移过程又是如何做的?…为了搞清楚这些问题,InfoQ 采访了参与 Prestomall 去 Oracle 全过程的阿里云技术团队。

为什么要去 Oracle?

过去几年,随着整个东南亚移动互联网的发展,Prestomall 也迎来了增长黄金期。以营收规模计算,过去 3 个财年,该公司实现了 256%的增长。Prestomall 业务的成功使得公司需要处理的数据量出现井喷式的增长,IT 费用也随之水涨船高,这也是 Prestomall 决定去 Oracle 的主要原因。


Oracle 的 License 费用太高了,随着 Prestomall 客户量和数据量的增加,这部分费用占据了大部分的 IT 预算,制约了其业务的发展,所以在授权还剩三个月的时候,Prestomall 开始寻找 Oracle 的替代方案。


另外,随着业务的快速发展,现有的 Oracle 数据库垂直架构限制了其弹性增长的需求,传统数据库不适应快速的互联网+发展,这也使得 Prestomall 下定决心替换 Oracle。

技术选型

减少 IT 费用是 Prestomall 去 Oracle 的主要原因,所以最初在选择替代方案时,IT 费用是一个重要的指标,同时由于授权即将到期,迁移时间也是需要考虑的重要因素。

最开始的选型方案:更倾向于开源数据库

据了解,Prestomall 最初想到的替代方案有三种,分别是:


第一种,采用 Oracle 外的另一种商用数据库,如 IBM DB2, 微软 SQL Server 等;


第二种,使用开源数据库,例如 MySQL、PostgreSQL;


第三种,保留 Oracle,继续续费 License;


Prestomall 想要彻底去 Oracle,摆脱传统传统商业数据库厂商的锁定,所以排除了第一种和第三种方案。其实保留 Oracle 或者使用其它商业数据库本就是权宜之举,除非没有可行的办法或者时间来不及,才会保留 Oracle,毕竟业务的正常运行是必须要保障的事情。不过,Prestomall 团队也意识到,如果继续拖延的话,未来去 Oracle 的困难和挑战将会更大。


经过一番评估之后,Prestomall 团队更倾向于选择开源数据。在备选的开源数据库产品中,PostgreSQL 比 MySQL 提供了更多的 SQL 功能,应用方面也与 Oracle 更加贴近,并且迁移成本也较低,自然成为了技术选型的第一选择。


在有了初步的技术选型之后,Prestomall 团队就迁移方案做了进一步细化的评估:


第一, 选取的数据库与已有的 Oracle 有多大的兼容性 ?


第二, 延用已有的本地部署解决方案,还是迁移上云?


第三, 迁移的工作量和时间究竟会多久?


第四, 采用新的技术方案,是否有足够的技术支持?

最终选型方案:PolarDB + ADAM + DTS + 专家服务

Prestomall 最终选定的替代方案是 PolarDB + ADAM + DTS + 专家服务。说实话,这个方案有点出人意料,毕竟最开始这个方案并没有出现在 Prestomall 的选择列表中,而且 Prestomall 原有的 Oracle 数据库是部署在本地的,选择了 PolarDB 就意味着数据库要迁移上云。


最终方案中的 PolarDB 是阿里云自主研发的关系型分布式云原生数据库,兼容三种数据库引擎:MySQL、PostgreSQL、高度兼容 Oracle 语法;ADAM 是数据库和应用迁移服务,可覆盖 Oracle 迁移的全生命周期;DTS 支持 RDBMS、NoSQL、OLAP 等数据源间的数据交互,集数据迁移/订阅/同步于一体。


那么,为什么最终会选择这个方案呢?阿里云数据库与应用迁移产品总监杨霖表示主要原因其实有三个:


一是上云适配业务发展。之前 Prestomall 使用的是本地 Oracle 数据库,而选择 PolarDB 就可以享受到云数据库弹性扩展的能力,按需申请资源,对于电商企业而言这种模式非常适配业务。


二是迁移成本最优。这里的成本不单单是指迁移后数据库资源的使用费用,同时也包括了迁移的工作量、代码的修改量以及迁移时间等其它成本。经过评估,PolarDBD 与 Oracle 数据库的兼容性非常高,整体迁移成本最优。


三是风险整体可控,技术支持有保障。2000 年,阿里开始使用 Oracle 数据库,2008 年,决定去 Oracle 数据库。当前 Prestomall 的遭遇,跟十年前的阿里一样,而在过去十几年中,阿里的技术人员趟出了从 Oracle-RAC 数据库到 PolarDB,从云下到云上的搬迁,积累了很多经验,并沉淀了类似 ADAM、DTS 这样的产品。这些成功经验对 Prestomall 来说有着很大的吸引力。


据透露,在最初的提案阶段,阿里云数据库团队通过 ADAM 给出了一个超详细的改造计划,包括 DB 层面如何去自动映射、自动解析、自动转换,以及应用层每一行代码如何改造。同时,还对不同数据库产品的兼容性做了比较定量的代码改造分析。


阿里云数据库国际站产品负责人德迈介绍:“使用 ADAM 分析之后,我们发现,如果不使用 ADAM,从 Oracle 迁移到 PostgreSQL,80%以上的代码是需要修改的,如果使用 ADAM 迁移到 PostgreSQL,10%左右的代码是需要修改的,而如果迁移到 PolarDB,只有 5%的代码是需要修改的。”而这也是 PolarDB 入选最终迁移方案的重要原因。

迁移过程

确定了迁移方案之后,接下来要做的就是具体的迁移工作了。据了解,Prestomall 整个去 Oracle 可以六个阶段:


第一步是去 Oracle 的技术选型,前面我们详细介绍了选型过程,这里不再赘述。


第二步是去 Oracle 的赋能,即在实现与 Oracle 数据库解耦的同时,实现业务 IT 架构升级,获得更大的业务自由度。


第三步是业务改造,对于所有想要去 Oracle 的客户来说,这是最难的部分。业务改造面临的两大问题是工作量评估和兼容性。


第四步是数据迁移,不仅要保证全量和增量数据的一致性,同时还要提供数据回流的能力,让数据上得来下得去。


第五步是测试与调优,虽然 PolarDB 与 Oracle 兼容,但是始终是两个产品,各自有各自的产品特性,因此迁移上去之后还需要做进一步的调试。


第六步是割接与护航,在完成上线割接之后,还会有两个星期的阿里技术专家的保驾护航。


值得一提的是,在迁移过程中,ADAM 有两个功能发挥了很大的作用,一个是自动转换的功能,可以帮助使用者将原有的 Oracle SQL 自动改造成 PolarDB 兼容的 SQL。另一个是自动学习功能,虽然 PolarDB 与 Oracle 是高度兼容的,但也会有语法差异,而 ADAM 的 SQL 语法染色功能会使用不同的颜色来标注语法差异,帮助使用者快速领悟到语法差异规则。


据了解,目前 Prestomall 的业务流量几乎全部迁移到了 PolarDB 上,只剩邮件系统中的两张表还在做反向同步。


另外提到数据库迁移,很多人都会关心安全性的问题,尤其 Prestomall 作为东南亚的一家电商平台,在流程方面会更关注业务保护。据阿里云高级 DBA 专家郑旦介绍,在数据保护和业务稳定方面,阿里云主要做了两个层面的工作:第一个层面,DTS 不仅完成了数据迁移的工作,同时还在这个过程中做了数据校验;第二个层面,ADAM 对 Prestomall 系统的兼容性和兼容性结果做了一致性的检查。

写在最后

业界一直有“天下苦 Oracle 久矣”的说法,但是在实际去 Oracle 的过程中,总会犯难。那么,业界在去 Oracle 实践时,通常都有哪些选择呢?


阿里云智能数据库事业部产品总监叶正盛(斗佛)表示:“其实去 Oracle 的选择不是很多,业内常使用的基本上只有三种,一种是迁移到其它商业数据库,但这种方式用的较少;第二种是选择一种兼容度较高的数据库,这种方式的优势是业务基本不用做大的改造;第三种是切换到分布式数据库,这种方式的劣势是需要在业务上做重新设计,但优点是完成之后,可以享受分布式带来的红利。”


2020-02-12 09:352093
用户头像

发布了 497 篇内容, 共 324.8 次阅读, 收获喜欢 1920 次。

关注

评论

发布
暂无评论
发现更多内容

微信朋友圈复杂度分析&架构设计

AragornYang

架构训练营 架构实战营

微信朋友圈高性能复杂度分析

Bear

「架构实战营」

六年安卓开发的技术回顾和展望 | 社区征文

拭心

android 程序员人生 shixinzhang 新春征文 2月月更

react源码解析6.legacy模式和concurrent模式

buchila11

React

TDengine在TCL空调能源管理平台的实践

TDengine

数据库 大数据 tdengine 物联网

我做基础架构学到的42件事

多颗糖

数据库 架构 架构师 基础架构

微信朋友圈的高性能复杂度分析

凌波微步

「架构实战营」

如何用 Python 实现一个单链表

宇宙之一粟

Python 数据结构 单向链表 2月月更

「架构实战营」模块二作业 朋友圈复杂度

hxb

「架构实战营」

重磅消息·OpenMLDB官方网站 今日正式上线!

第四范式开发者社区

人工智能 机器学习 开源项目 AI Studio 特征平台

[架构实战营]-朋友圈的高性能架构设计

邹玉麒

「架构实战营」

微信朋友圈的高性能复杂度分析

石小天

架构实战营

Kotlin语法手册(二)

寻找生命中的美好

android kotlin 安卓

WebRTC 如何在安卓系统上采集音频数据 | 社区征文

liuzhen007

音视频 WebRTC 新春征文 2月月更

微信朋友圈高性能架构设计

五月雨

架构实战营 「架构实战营」

计算机毕业设计安卓疫苗预约APP源码,后台java springboot

清风

安卓 计算机毕业设计

架构实战营模块九作业

spark99

架构实战营

Linux系统编程-Shell脚本基本使用(数组、函数、字符串处理)

DS小龙哥

Shell 2月月更

最全总结 | Android 系统抓包喂饭教程!

星安果

android 抓包

《MySQL入门很轻松》第3章:数据库的创建与操作

乌龟哥哥

:MySQL 数据库 2月月更

国内外最顶级的十大敏捷项目开发管理工具盘点

爱吃小舅的鱼

Web Components系列(七) ——自定义组件的生命周期

编程三昧

前端 组件化 2月月更 WebComponent

Linux系统编程-进程创建(fork)、外部程序调用(exec)

DS小龙哥

进程 fork 2月月更

使用 Cilium 增强 Kubernetes 网络安全

张晓辉

Kubernetes 云原生 ebpf cilium

微信朋友圈的高性能复杂度

Geek_16d2b8

#架构训练营

微信朋友圈的高性能复杂度分析

Leo

架构实战营

微信朋友圈复杂度分析与设计

刘帅

几种数据库存储引擎比较

乌龟哥哥

:MySQL 数据库 2月月更

微信朋友圈高性能复杂度分析

浪飞

Linux系统编程-进程概念、进程管理、信号处理

DS小龙哥

2月月更

Redis 在 vivo 推送平台的应用与优化实践

vivo互联网技术

服务器 消息推送 redis'

独家揭秘东南亚电商平台 Prestomall 去 Oracle 的全过程_数据库_田晓旭_InfoQ精选文章