OceanBase开发者大会实录：SaaS 场景降本50%！石基零售应用 OB Cloud 实践_ocenbase搭载 saas

本文来自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 提供的联合解决方案。