![cover](https://img-blog.csdnimg.cn/img_convert/deb2739eb78aa79e75330d98d83b9bf4.png)
OceanBase开发者大会实录:SaaS 场景降本50%!石基零售应用 OB Cloud 实践
新时代的零售行业需要怎样的数据库?请观看2024OceanBase开发者大会中,石基零售助理总裁 、ROC 产品事业部负责人陈亮的演讲实录—《石基零售与 OB Cloud 零售行业应用实践》
本文来自2024 OceanBase开发者大会,石基零售助理总裁 、 ROC 产品事业部负责人陈亮的演讲实录—《石基零售与 OB Cloud 零售行业应用实践》。完整视频回看,请点击这里>>
大家下午好!我是石基零售的陈亮。今天和大家分享一下石基零售与 OB Cloud 在零售行业的应用实践。
石基零售是零售行业的解决方案提供商与服务商,业务覆盖百货、超市、购物中心、便利店、专营专卖等。连锁与零售行业的百强企业,石基服务的客户占比超过 50%。海量数据是零售行业现在面临的最大问题之一,为了应对这一挑战,常规的做法是不断增加服务器、不断优化 SQL 语句,这给零售商和软件商提出了很多挑战。
接下来,我分享一下石基零售和 OB Cloud 在零售行业的应用实践。
一、新时代的零售行业需要怎样的数据库
整个零售行业的数据库转型经历了四阶段。如图所示:
第一个阶段是 ERP,用一个单体数据库解决所有问题,比较看重单体数据库的 I/O 能力。
第二个阶段,随着零售时代的发展,出现小程序、APP 等以顾客为中心的零售经营模式,这时使用单体数据库,面对高并发或者未知并发的能力是不够的。这个阶段,数据库的选择上一般偏向 MySQL、云上数据库 等。
第三个阶段,出现了新零售、业务中台、数据中台。原来的技术方案是用 MySQL 或者分库分表的方式解决所有问题,但这种方案在实际应用中会面临一些问题。
第四个阶段,AI +大数据时代,数据库最核心的能力是高效的 AP 能力。
接下来看一下零售行业的单体数据库在高并发场景下的支持情况。
举个例子,杭州某客户大概有 5000 家店,服务器近 40 台。如果业务量继续增长的话,还要再加服务器。从业务的角度来看,加服务器满足了性能需求;但是从运维、数据同步的视角来看,这些问题都没有解决。
前几年出现混合数据库。有一部分业务用 Oracle,在门店这种高并发业务场景下,改用 MySQL 数据库,让它做数据通讯。当时 ETL 工具尚不健全,所以自己用 Java 写工具,把 Oracle 的数据同步到 SQL Server,同样的工具开发成本很高。
现阶段,客户的核心诉求是怎么保证高可用、高性能。原来在用 MySQL 时会遇到这样的情况,一条 SQL 没写好,整个数据库的性能都会受到影响。但是使用 SQL 优化的工具加强监控也不是常态,因为业务还处于生产状态。其他还有在不停机的情况下实现弹性扩缩容、减少运维成本、统一技术栈等,都是零售行业客户的诉求。
围绕这些诉求,我们一直在寻找一款既能降低开发成本,又能降低运维成本的数据库。
二、全方位评估,选择 OceanBase
首先,从性能层面评估,兼容性是第一考虑要素。
原来使用的 MySQL 数据库,如何无缝迁移到目标数据库。在比较了市面上的数据库后,我认为分布式数据库一定是未来的主流。所以在选型时,我们尝试使用 OceanBase 作为未来的数据库。我们庞大的系统,从 MySQL 数据库迁移到 OceanBase,只花了一周时间,在这期间也感谢 OceanBase 团队对我们的支持。
第二,高并发能力。
数据库除了需要支持线下运营外,还要支撑线上的相应业务。如何解决高并发问题?OceanBase 强大的 AP 能力为我们提供了保障,很好地支撑了线上线下业务。
原来在石基零售,线下业务因为数据量庞大,需要单独搭一套数据库,线上业务搭载这个数据库,之后再把数据回流或者同步到线下业务系统。而 OceanBase 的 AP 能力解决了这个问题,从开发的视角来看,不需要再考虑这些问题。
第三,稳定性。
在稳定性方面,我们也和市面上的主流数据库做了比较,而 OceanBase 可以完全支持我们作为一个解决方案提供商的稳定性。我们在联华、华润万家等零售百强 TOP 10 的企业都做了相应的试点。
第四,高性价比。
OceanBase可以做混合性部署,这是第一个方案;第二个方案,我们测试了 OceanBase 的压缩比例,存储可以压缩到 70%。我们可以基于存储成本的降低,进而降低整体成本。
三、石基零售和 OceanBase 的联合解决方案
(一)适合 SaaS 场景的多租户能力
基于 OceanBase 的多租户架构,将多个不同业务/不同企业的数据库实例集中整合,提升资源利用率,同时基于 Paxos 的多副本机制可以保证每个资源单元的高可用能力。
既适用于中大型企业内部大量不同业务链路的资源池化,也适用于各个行业 SaaS 服务商,为不同客户提供不同规格的实例,保证资源隔离性的同时降低成本。
在零售行业,有的属于小客户客群。小客户不会做线下部署,更多选择多租户的部署,看重 SaaS 化产品的能力。基于多租户场景和 SaaS 化场景的特征,我们做了数据库迁移,很好地控制了成本。
举个例子。原来 2C8G 的小商户,通过弹性扩容,扩到 16C64G 等。我们可以面向不同商超的客户类型,让多租户的应用弹性化,做容量的弹性扩容,有助于我们控制整体成本。
(二)丰富的工具包:平滑迁移,开发无忧
从运维的视角来看,系统从原来庞大的数据体系迁到新的数据体系里面,工具很重要。没有好的工具生态,仅使用 SQL 的话,会增加运维人员的工作量,整体成本也会更大。
OMS 有很好的迁移能力,包括表结构的迁移。如果原来使用 MySQL,存储过程都可以迁移,数据迁移和同步对我们来说是无忧的。
另外,在迁移之前,我们需要对数据库能否迁移以及迁移的效果做一个评估,而 OceanBase 的迁移评估体系也很方便。从客户的视角看 OceanBase 的运维管理,比如 MySQL 诊断、事件诊断等,OceanBase 提供了丰富的工具包;从开发者视角和客户运维的视角,基本上可以达到“开发无忧”的程度。
(三)一站式传统数据库上云
石基零售和 OceanBase 为商超行业提供一站式传统数据库上云解决方案。传统数据库上云存在一些风险和挑战:
第一,在微服务时代,基本上逻辑是在应用层里。再往前追溯 10 年,也会有存储过程,应用存储过程的迁移有一定的风险。
第二,客户观念的转变。商超零售行业,客户观念还停留在数据库靠不靠谱、花多少钱,客户观念要转变,可以先用社区版,也可以用混合式的部署。
第三,成本测算。整个行业都在降本增效,那么数据库迁到云上可以节省多少成本?投入的数据库成本,从哪里降低费用?答案是人员复用。人力成本会越来越高,所以我们的解决方案就建议基于 MySQL 的数据库上云。这里我们测试过了,也有成功的案例。
我们有大量基于 Oracle、Informix 等其他传统数据库的客户,按照业务划分,我们做了混合云的方案,一部分业务直接上云,一部分业务逐步上云。比如,十足就采用了混合云方案,一部分数据库在本地,一部分在云上。另外 SaaS 化的产品,我们也建议客户逐步迁移至云上。
四、石基零售结合 OB Cloud,商超行业案例
这里举一些石基零售和 OB Cloud 在商超行业的一些案例。
我们的数据量达到 PB 级,整个应用系统包括 ERP 系统、业财系统等。商超行业的数据量非常大,因此 ERP 系统线下并发量也非常高;业财系统的核心是经营分析,卖出一个商品的收益,不仅要解决进销差,还有财务上的分摊规则,一条销售会计十个科目,一条数据就会变成十条数据;经营分析报表更复杂,它是横向的报表;另外还有卡券系统、线上业务等。
我们把整体应用效果做了一个评估,硬件成本下降了 50%。这个地方是最触动我的。原来我们用微服务、Spring Cloud、K8s 部署时,一个软件系统 200 万,但是硬件投入可能要 50-60 万。而一些中小客户不愿意为硬件买单,这时我们面临的最大问题是系统太重,没法往下推。
使用 OB Cloud 以后可以解决几个问题。第一,数据库整合;第二,服务整合;第三,轻量化部署。从整体视角来看,硬件成本下降了 50% 。
从单体数据库的视角来看,压缩比例超过 70%,但是很容易忽略的一点是,传统数据库里,一份数据有多副本通过多个数据库的支撑,通过数据传输形成一套或者多套副本。使用 OB Cloud 以后,只需要一个数据库就能解决这些问题,整体压缩比例达到 70%。
在应用性能方面,官方统计的数据显示,OceanBase 是 MySQL 的 2-3 倍,但我们实际使用效果显示,可以达到 10 倍以上。为什么呢?原来使用单表时,仅一个表可能就有 2 亿条左右的数据,在MySQL 中,数据量越大,应用性能就会越慢。
举个例子,将某客户三年的数据导入到 OceanBase,不做集群部署,在同一 SQL 条件下,和 MySQL 的性能效果相差 10 倍,这是 4.3 版本的实际应用场景。4.3 版本比 4.2 版本的性能更高,但是稳定性略差一点。
对传统零售行业来讲,这里 OceanBase 还需要改进,尤其是分析报表层不固定,很难做大数据应用分析,很多基于 SQL 的小应用会用到临时表,类似于内存数据库,OceanBase 后面也计划用临时表。
五、规划未来
目前,我们运行了三套产品做试点。
第一块是数据报表,在联华的业财数据湖方案里(戳此复习《联华集团CTO楼杰:从成本中心到价值中心的跃迁》),隐含一个经营管报,它是报表的一部分,它可以通过数据,分析经营情况;
第二块是多租户体系下 SaaS 化产品,也在逐步迁移至 OceanBase;
第三块是 ERP 产品,我负责的事业部就是中大型零售商应用的 ERP 系统,在一个星期内全部迁移至 OceanBase,并且完成用户侧深层测试。
石基的这三类产品线基本上在 OceanBase 上得到了应用,且性能非常可观,同时也有两个客户开始上线。
未来,石基零售的深化应用OB Cloud整体规划分为两大类:
商超业务和购百业务逐步上云,同时做版本测试和原型试点。我们现在用的是 4.2 版本,将来会逐步把列式存储、行列混合存储做迁移。
最后,分享一下我们选择 OB Cloud 最核心的逻辑:第一,降低了开发成本,不需要分库分表,也不需要 MyCat 的中间件来解决高可用的问题,降低了开发成本。第二,从运维视角来看,可以在一个页面进行查询。第三,减少了数据通讯,使数据库的部署变得更轻。
如果连锁与零售行业的客户想通过数据库解决海量数据、高并发等问题,可以了解石基零售与 OceanBase 提供的联合解决方案。
4 月 20 日,2024 OceanBase 开发者大会在上海成功举办。在大会创新场景实践专场分论坛上,石基零售助理总裁、ROC 产品事业部负责人陈亮为大家带来《石基零售与 OB cloud 零售行业应用实践》主题分享。以下内容根据演讲实录整理而成。
大家下午好!我是石基零售的陈亮。今天和大家分享一下石基零售与 OB Cloud 在零售行业的应用实践。
石基零售是零售行业的解决方案提供商与服务商,业务覆盖百货、超市、购物中心、便利店、专营专卖等。连锁与零售行业的百强企业,石基服务的客户占比超过 50%。海量数据是零售行业现在面临的最大问题之一,为了应对这一挑战,常规的做法是不断增加服务器、不断优化 SQL 语句,这给零售商和软件商提出了很多挑战。
接下来,我分享一下石基零售和 OB Cloud 在零售行业的应用实践。
一、新时代的零售行业需要怎样的数据库
整个零售行业的数据库转型经历了四阶段。如图所示:
第一个阶段是 ERP,用一个单体数据库解决所有问题,比较看重单体数据库的 I/O 能力。
第二个阶段,随着零售时代的发展,出现小程序、APP 等以顾客为中心的零售经营模式,这时使用单体数据库,面对高并发或者未知并发的能力是不够的。这个阶段,数据库的选择上一般偏向 MySQL、云上数据库 等。
第三个阶段,出现了新零售、业务中台、数据中台。原来的技术方案是用 MySQL 或者分库分表的方式解决所有问题,但这种方案在实际应用中会面临一些问题。
第四个阶段,AI +大数据时代,数据库最核心的能力是高效的 AP 能力。
接下来看一下零售行业的单体数据库在高并发场景下的支持情况。
举个例子,杭州某客户大概有 5000 家店,服务器近 40 台。如果业务量继续增长的话,还要再加服务器。从业务的角度来看,加服务器满足了性能需求;但是从运维、数据同步的视角来看,这些问题都没有解决。
前几年出现混合数据库。有一部分业务用 Oracle,在门店这种高并发业务场景下,改用 MySQL 数据库,让它做数据通讯。当时 ETL 工具尚不健全,所以自己用 Java 写工具,把 Oracle 的数据同步到 SQL Server,同样的工具开发成本很高。
现阶段,客户的核心诉求是怎么保证高可用、高性能。原来在用 MySQL 时会遇到这样的情况,一条 SQL 没写好,整个数据库的性能都会受到影响。但是使用 SQL 优化的工具加强监控也不是常态,因为业务还处于生产状态。其他还有在不停机的情况下实现弹性扩缩容、减少运维成本、统一技术栈等,都是零售行业客户的诉求。
围绕这些诉求,我们一直在寻找一款既能降低开发成本,又能降低运维成本的数据库。
二、全方位评估,选择 OceanBase
首先,从性能层面评估,兼容性是第一考虑要素。
原来使用的 MySQL 数据库,如何无缝迁移到目标数据库。在比较了市面上的数据库后,我认为分布式数据库一定是未来的主流。所以在选型时,我们尝试使用 OceanBase 作为未来的数据库。我们庞大的系统,从 MySQL 数据库迁移到 OceanBase,只花了一周时间,在这期间也感谢 OceanBase 团队对我们的支持。
第二,高并发能力。
数据库除了需要支持线下运营外,还要支撑线上的相应业务。如何解决高并发问题?OceanBase 强大的 AP 能力为我们提供了保障,很好地支撑了线上线下业务。
原来在石基零售,线下业务因为数据量庞大,需要单独搭一套数据库,线上业务搭载这个数据库,之后再把数据回流或者同步到线下业务系统。而 OceanBase 的 AP 能力解决了这个问题,从开发的视角来看,不需要再考虑这些问题。
第三,稳定性。
在稳定性方面,我们也和市面上的主流数据库做了比较,而 OceanBase 可以完全支持我们作为一个解决方案提供商的稳定性。我们在联华、华润万家等零售百强 TOP 10 的企业都做了相应的试点。
第四,高性价比。
OceanBase可以做混合性部署,这是第一个方案;第二个方案,我们测试了 OceanBase 的压缩比例,存储可以压缩到 70%。我们可以基于存储成本的降低,进而降低整体成本。
三、石基零售和 OceanBase 的联合解决方案
(一)适合 SaaS 场景的多租户能力
基于 OceanBase 的多租户架构,将多个不同业务/不同企业的数据库实例集中整合,提升资源利用率,同时基于 Paxos 的多副本机制可以保证每个资源单元的高可用能力。
既适用于中大型企业内部大量不同业务链路的资源池化,也适用于各个行业 SaaS 服务商,为不同客户提供不同规格的实例,保证资源隔离性的同时降低成本。
在零售行业,有的属于小客户客群。小客户不会做线下部署,更多选择多租户的部署,看重 SaaS 化产品的能力。基于多租户场景和 SaaS 化场景的特征,我们做了数据库迁移,很好地控制了成本。
举个例子。原来 2C8G 的小商户,通过弹性扩容,扩到 16C64G 等。我们可以面向不同商超的客户类型,让多租户的应用弹性化,做容量的弹性扩容,有助于我们控制整体成本。
(二)丰富的工具包:平滑迁移,开发无忧
从运维的视角来看,系统从原来庞大的数据体系迁到新的数据体系里面,工具很重要。没有好的工具生态,仅使用 SQL 的话,会增加运维人员的工作量,整体成本也会更大。
OMS 有很好的迁移能力,包括表结构的迁移。如果原来使用 MySQL,存储过程都可以迁移,数据迁移和同步对我们来说是无忧的。
另外,在迁移之前,我们需要对数据库能否迁移以及迁移的效果做一个评估,而 OceanBase 的迁移评估体系也很方便。从客户的视角看 OceanBase 的运维管理,比如 MySQL 诊断、事件诊断等,OceanBase 提供了丰富的工具包;从开发者视角和客户运维的视角,基本上可以达到“开发无忧”的程度。
(三)一站式传统数据库上云
石基零售和 OceanBase 为商超行业提供一站式传统数据库上云解决方案。传统数据库上云存在一些风险和挑战:
第一,在微服务时代,基本上逻辑是在应用层里。再往前追溯 10 年,也会有存储过程,应用存储过程的迁移有一定的风险。
第二,客户观念的转变。商超零售行业,客户观念还停留在数据库靠不靠谱、花多少钱,客户观念要转变,可以先用社区版,也可以用混合式的部署。
第三,成本测算。整个行业都在降本增效,那么数据库迁到云上可以节省多少成本?投入的数据库成本,从哪里降低费用?答案是人员复用。人力成本会越来越高,所以我们的解决方案就建议基于 MySQL 的数据库上云。这里我们测试过了,也有成功的案例。
我们有大量基于 Oracle、Informix 等其他传统数据库的客户,按照业务划分,我们做了混合云的方案,一部分业务直接上云,一部分业务逐步上云。比如,十足就采用了混合云方案,一部分数据库在本地,一部分在云上。另外 SaaS 化的产品,我们也建议客户逐步迁移至云上。
四、石基零售结合 OB Cloud,商超行业案例
这里举一些石基零售和 OB Cloud 在商超行业的一些案例。
我们的数据量达到 PB 级,整个应用系统包括 ERP 系统、业财系统等。商超行业的数据量非常大,因此 ERP 系统线下并发量也非常高;业财系统的核心是经营分析,卖出一个商品的收益,不仅要解决进销差,还有财务上的分摊规则,一条销售会计十个科目,一条数据就会变成十条数据;经营分析报表更复杂,它是横向的报表;另外还有卡券系统、线上业务等。
我们把整体应用效果做了一个评估,硬件成本下降了 50%。这个地方是最触动我的。原来我们用微服务、Spring Cloud、K8s 部署时,一个软件系统 200 万,但是硬件投入可能要 50-60 万。而一些中小客户不愿意为硬件买单,这时我们面临的最大问题是系统太重,没法往下推。
使用 OB Cloud 以后可以解决几个问题。第一,数据库整合;第二,服务整合;第三,轻量化部署。从整体视角来看,硬件成本下降了 50% 。
从单体数据库的视角来看,压缩比例超过 70%,但是很容易忽略的一点是,传统数据库里,一份数据有多副本通过多个数据库的支撑,通过数据传输形成一套或者多套副本。使用 OB Cloud 以后,只需要一个数据库就能解决这些问题,整体压缩比例达到 70%。
在应用性能方面,官方统计的数据显示,OceanBase 是 MySQL 的 2-3 倍,但我们实际使用效果显示,可以达到 10 倍以上。为什么呢?原来使用单表时,仅一个表可能就有 2 亿条左右的数据,在MySQL 中,数据量越大,应用性能就会越慢。
举个例子,将某客户三年的数据导入到 OceanBase,不做集群部署,在同一 SQL 条件下,和 MySQL 的性能效果相差 10 倍,这是 4.3 版本的实际应用场景。4.3 版本比 4.2 版本的性能更高,但是稳定性略差一点。
对传统零售行业来讲,这里 OceanBase 还需要改进,尤其是分析报表层不固定,很难做大数据应用分析,很多基于 SQL 的小应用会用到临时表,类似于内存数据库,OceanBase 后面也计划用临时表。
五、规划未来
目前,我们运行了三套产品做试点。
第一块是数据报表,在联华的业财数据湖方案里(戳此复习《联华集团CTO楼杰:从成本中心到价值中心的跃迁》),隐含一个经营管报,它是报表的一部分,它可以通过数据,分析经营情况;
第二块是多租户体系下 SaaS 化产品,也在逐步迁移至 OceanBase;
第三块是 ERP 产品,我负责的事业部就是中大型零售商应用的 ERP 系统,在一个星期内全部迁移至 OceanBase,并且完成用户侧深层测试。
石基的这三类产品线基本上在 OceanBase 上得到了应用,且性能非常可观,同时也有两个客户开始上线。
未来,石基零售的深化应用OB Cloud整体规划分为两大类:
商超业务和购百业务逐步上云,同时做版本测试和原型试点。我们现在用的是 4.2 版本,将来会逐步把列式存储、行列混合存储做迁移。
最后,分享一下我们选择 OB Cloud 最核心的逻辑:第一,降低了开发成本,不需要分库分表,也不需要 MyCat 的中间件来解决高可用的问题,降低了开发成本。第二,从运维视角来看,可以在一个页面进行查询。第三,减少了数据通讯,使数据库的部署变得更轻。
如果连锁与零售行业的客户想通过数据库解决海量数据、高并发等问题,可以了解石基零售与 OceanBase 提供的联合解决方案。
更多推荐
所有评论(0)