多点 DMALL 与 OceanBase：实现租户间资源完全隔离与低成本系统升级

本文摘自《OceanBase社区版在泛互场景的应用案例研究》电子书，点击链接获取完整版内容。

作者：杨家鑫，多点数据库团队 DBA

在当今数字化转型的大潮中，企业面临着诸多挑战，尤其是在零售 SaaS 场景下，数据处理的复杂性和成本问题尤为突出。作为零售数字化领域的先锋，我们不仅是国内顶尖的全局数字化解决方案提供商，更在亚洲市场上占据领先地位。我们拥有上百个全渠道系统，涵盖会员管理、商品、营销、O2O、POS 系统、WMS 物流、AI 出清、AI 导购等多个关键环节，为零售企业提供全方位的数字化支持。我们的客户遍布国内、东南亚及欧洲等地，其中包括知名网红商家、全国性头部连锁便利店、合资连锁商超等。在业务高速增长的背后，我们也面临着来自零售 SaaS 场景和业务系统瓶颈的挑战。

本文将结合多点 DMALL 面临的挑战、OceanBase 数据库的优势与选择、多点 DMALL 应用 OceanBase 的实践、OceanBase 在多租户架构下的资源隔离实践等内容，分享我们借助 OceanBase 升级数据库架构、简化技术栈，从而实现降本提效的实践经验。

一、多点 DMALL 面临的挑战

（一）系统复杂度高

多点 DMALL 采用了微服务架构，其全流程业务环节繁多，系统应用规模庞大。与之对应的是，数据库数量已然超过 500 个。此外，随着系统持续迭代升级，数据规模呈现出不断增长的态势，这使得运维管理的难度日益增大。就如同在一张庞大而复杂的网络中，每一个节点都承载着关键业务，牵一发而动全身，运维人员需要时刻保持警惕，以应对可能出现的各种问题。

（二）业务增长快，水平扩展需求增多

随着业务的蓬勃发展，我们积极制定了出海战略，旨在海外开拓新的业务版图。然而，基于地区数据安全法的严格要求，必须独立部署一整套全新的系统来承接海外业务流量。在初始部署阶段，由于难以精准预估后期业务规模以及数据增长速度，数据库资源在初始阶段的分配成为了一大难题。为了有效控制成本，常见的做法是先分配较少的部署资源。但很快，业务的快速增长带来了数据的迅猛增长，此时如何快速实现扩容，成为了摆在面前的一道棘手难题。这就好比在高速行驶的列车上，突然发现前方轨道需要紧急拓宽，而时间却十分紧迫。

（三）需要在同一个集群中服务大量商家

便利店和连锁商超的 SKU（最小存货单位）规模差异较大，从几千到几万不等。在这种情况下，很难为每个商家独立部署一套系统。因此，我们的 SaaS 系统需要支持上百个中小商家客户，所有商家产生的数据在底层共享数据库资源。这就如同在一个大仓库中，不同商家的货物需要合理存放和管理，既要保证各自的独立性，又要充分利用仓库的空间，实现资源的高效共享。

（四）资源成本高昂

零售作为与民生息息相关的行业，其业务系统必须保持全天候运行。无论是供应链的采购、销售、物流环节，还是电商业务，除白天正常作业外，夜间乃至凌晨也依然活跃。这导致大量数据源源不断地涌入数据库，使得资源成本如同一条不断上升的斜线，呈现出无限制增长的态势。多点 DMALL 主要使用六种开源数据库，在整个生产环境中，数据库实例已超过一万个，数据空间规模也接近 10PB 级别。如此庞大的数据量和复杂的数据库环境，无疑给资源成本控制带来了巨大挑战。

（五）运维成本居高不下

在使用多种数据库的过程中，我们遭遇了一系列棘手问题，包括技术复杂性带来的难题、高昂的运维成本、烦琐的管理成本、巨大的学习成本以及复杂的交付成本。一套私有化环境的交付涉及上百个系统，以及上百套数据库集群和数百个数据库实例。这就好比搭建一座宏伟的建筑，每一个部件都需要精心安装和调试，任何一个环节出现问题都可能影响整个系统的正常运行，因此运维成本始终居高不下。

二、OceanBase 数据库的优势与选择

（一）分布式数据库的优势

为了应对上述挑战，我们开始了数据库选型。由于分布式数据库支持更大的容量规模，具备透明扩展的能力，提供金融级数据安全，并且可以提高开发效率以及降低运维成本，能够更好地支撑业务发展。因此，我们坚定地认为它是数据库未来的趋势，此次选型仅调研了分布式数据库产品。

（二）基于业务的选型考虑因素

首先，从扩展性角度考虑，我们面临诸多挑战。目前，多个 MySQL 单库的数据量已超过 4 TB，并且仍在快速增长。当我们将最大的 MySQL 库切换到分布式数据库后，数据量已增长至 29 TB。面对数据的快速增长及 MySQL 容量瓶颈，DBA （数据库管理员）深感忧虑：

• 一方面，我们不断敦促研发团队进行数据清理和归档，但效果往往不佳，因为他们的主要工作是业务需求迭代，难以兼顾数据清理。

• 另一方面，考虑继续扩展磁盘空间。在云环境下，扩展空间相对容易，云厂商提供的块存储单盘容量可达 32 TB 或更大。然而，数据持续增长，仅通过扩展磁盘空间只是将问题延后，无法从根本上解决问题，未来可能会面临更大的困境。

• 此外，我们还可以选择分库分表的方案，但这操作烦琐、风险较高，且需要耗时数月。因为该方案会损害 SQL 能力，代码改造不可避免。

因此，我们期望利用分布式数据库透明且可扩展的能力，平稳支撑业务的快速增长。

其次，从运维成本角度考虑，在保证系统稳定性的前提下，我们致力于降低运维复杂度。以 MySQL 为例，假设一个数据库（database）是一个“蛋”，一个 MySQL 实例是一个“篮子”，那么部署 1000 个数据库时，应该如何合理分配到多个 MySQL 实例中？哪些数据库应该放在同一个实例中？如果将两个对资源要求都很高的重要数据库放在同一个实例中，可能会导致资源抢占。另外，如支付类数据库，虽然数据量不大，但对业务要求极高，也不宜与其他数据库放在同一个实例中。由于业务差异、优先级不同、数据增长速度各异以及 QPS（每秒查询数） 要求不同，DBA 经常需要调整数据库分布。即便不考虑资源成本，仅运维挑战就已相当大。我们期望分布式数据库能够解决这一问题，帮助 DBA 自动调整数据库分布（见图 1）。

图 1 使用分布式数据库实现“自动挪蛋”示意图

最后，从高可用角度考虑，我们期望保证集群的高可用能力。在运维 MySQL 集群时，我们通常采用 MHA、Orchestrator 等工具实现高可用，但它们都是“外挂”形式，本质上无法解决网络分区导致的脑裂问题（见图 2）。因为数据库和 MHA 组件是两个独立的软件，不在同一个进程内，缺乏一致性协同控制。相比之下，MySQL 的 Group Replication 这类高可用架构更为可靠，它与 OceanBase 或 TiDB 等分布式数据库一样，基于 Paxos 或 Raft 分布式一致性协议，可以实现 RPO=0（数据丢失为零），RTO<30s（恢复时间目标小于 30s）的高可用目标。

图 2 使用分布式数据库实现“金融级高可用”示意图

（三）产品选型测试数据

基于上述选型因素，我们选择了原生分布式数据库 OceanBase，并进一步对比了 OceanBase 与 MySQL 在表读写、表只读、表只写等方面 QPS 的表现，以及二者在存储成本方面的差异。表 1 为此次产品选型测试的相关配置。

表 1 产品选型测试的相关配置

在 OceanBase 与 MySQL 配置相同的情况下，对比了包含 10 张 3000 万条记录的 sysbench 表，我们发现：当并发数小于 20 时，MySQL 的表现略好于 OceanBase。但无论是 QPS 还是延迟，随着并发数的增加，OceanBase 的性能都会逐渐接近并可能超过 MySQL。关于 OceanBase 不同配置的对比如下（见图 3）。

图 3 测试结果 1

对于单机部署的模式，选择通过连接 OBProxy 访问 OBServer 还是直接连接 OBServer，会影响其在 10 张 3000 万条记录的 sysbench 表读写 QPS 的表现。测试结果显示，直接连接 OBServer 的性能比通过 OBProxy 连接的性能高 30%~50%。因此，对于单机部署的模式，我们建议直接连接 OBServer，以避免通过 OBProxy 访问 OBServer 时产生的额外网络开销。

在不同租户内存配置下，性能也会有所不同。测试结果显示，32GB 租户内存相比 16GB 租户内存，性能提升约 14%（见图 4）。

图 4 测试结果 2

（三）OceanBase 与 MySQL 表空间对比

在生产环境监控快照场景中，我们将 20 张表共计 5 亿数据量从 MySQL 迁移到 OceanBase，发现表空间占用降低了 60%（见图 5）。

图 5 表空间对比结果

基于上述迁移过程中的测试数据，我们最终决定在生产环境中上线 OceanBase。总的来说：

• 在生产环境监控快照场景中，对比 MySQL 存储（单副本）和 OceanBase 存储（单副本），我们发现 OceanBase 的数据压缩率达到了 6:1，显示出 OceanBase 优秀的数据压缩能力。

• 在单机部署并且连接 OBProxy 的情况下，当并发度较低时，OceanBase 的 QPS 和平均延迟表现略逊于 MySQL（但值得注意的是，OceanBase 的最低 QPS 也过万，且租户内存越高，QPS 性能越好；最低平均延迟为 3ms）。然而，随着并发度的逐渐上升，OceanBase 各项性能的提升比例高于 MySQL。具体来说，当并发度超过 200 之后，OceanBase 的各项性能会逼近甚至超过 MySQL。

• MySQL 采用一层架构，而 OceanBase 采用两层架构（由 OBProxy 和 OBServer 组成）。在单机部署时，直接连接 OBServer 相比通过 OBProxy 连接，性能会提升 30%~50%。这主要是因为每多一层架构，网络层面的延迟消耗就会相应增加。

（四） OceanBase 选用原因

OceanBase 的选用原因如下。

(1) OceanBase 是单机分布式一体化数据库。这意味着它在两个方面具有显著优势：一方面，单机性能可以像 MySQL 单机一样实现低延迟、高性能，满足业务初期数据量较小时的极致性能需求；另一方面，分布式特性使得我们在业务高速增长期可以轻松扩展，几乎不受容量限制。这两个特性共同解决了业务在全生命周期内对性能和扩展性的需求，无需改代码、不停机即可迁移，并保证高性能。

(2) 作为原生的分布式数据库，OceanBase 天然具备分片自动迁移和负载均衡的可扩展能力，能够在业务无感知的情况下实现透明扩缩容。基于 Paxos 协议的极致优化，OceanBase 4.x 版本进一步提升了系统可用性，可以做到 RPO=0，RTO<8s。

(3) OceanBase 通过最小化分布式开销的架构设计，保证了数据库的高性能。同时，其高压缩比相比 MySQL 可节省成本 6 倍以上。此外，OceanBase 的多租户特性十分契合 SaaS 客户的业务场景，资源隔离和扩缩容操作非常容易。

关于分布式数据库的数据处理延迟和吞吐能力，我们需要明确以下几点：内存中读写数据的延迟在 0.1μs 级别，SSD 延迟约为 0.1ms，机房内网络延迟约为 0.1ms，同城机房间延迟约 3ms。内存的读写延迟与 SSD、网络之间相差了 100~1000 倍。在吞吐方面，内存读写可达到 100GB/s，而 SSD 约为 1～2GB/s，万兆网络约为 1.2GB/s，内存与 SSD、网络之间的吞吐能力相差约 100 倍。

值得注意的是，MySQL 作为单机数据库，其 InnoDB 和 Server 层在同一进程中，数据交互非常高效，因此在性能和延迟方面表现出色。然而，对于分布式数据库而言，计算存储分离架构往往带来网络 I/O 开销，这是设计上的性能瓶颈。OceanBase 的独特之处在于其架构设计，将 SQL 引擎、存储引擎和事务引擎实现在一个进程里，OBServer 既做计算又做存储。应用通过 OBProxy 连接 OBServer 集群，OBServer 节点会把数据路由信息上报给 OBProxy。OBProxy 在接收到应用层 SQL 后，根据路由信息直接转发 SQL 到最合适的 OBServer 上去执行（见图 6）。如果数据都在同一个 OBServer 节点上，那么 SQL 执行过程就是单机的，类似于 MySQL，从而最大程度减少了网络 I/O 开销。

图 6 OceanBase 的架构设计

（五） OceanBase 选用性能

当数据量较大或并发更高时，OceanBase 的性能明显优于 MySQL。为了理解这一现象，我们对 OceanBase 的架构进行了深入研究。

(1) OceanBase 同时兼具单机低延时和分布式高吞吐的特性。在生产业务数据中，OceanBase 的单机事务占比可以达到 80%以上。这是因为 OceanBase 中数据分片的粒度是一个表或分区。因此，当更新的只是一张非分区表，或者分区表的单个分区时，该事务必定是单机事务。更进一步，如果事务中涉及的多个表都在同一台机器中，那么该事务也会是单机事务。

(2) 通过 Table group 机制优化跨机 join，可以将部分跨机事务优化成单机事务。分区粒度的设计保证了大部分事务是单机的。再通过 Table group 机制优化高频的跨机 join 后，单机事务占比可以进一步提升。如果整个业务中有 90%以上的事务都是单机事务，那么性能自然会非常好。

(3) OceanBase 系统通过区分查询的优先级，使得小查询优先执行。大查询最多只能占用 30%的工作线程，这一比例可以通过 arge_query_worker_percentage 配置进行调整。在没有小查询时，大查询可以使用到 100%的工作线程。这一机制类似于高速公路的通行规则。例如，如果高速公路有三条车道，并且三条车道都有车行驶，那么后车很难超车。如果制定一个规则，让大车（大查询）只能走最右侧车道，而小车（小查询）还有两个车道可以通行，那么这样的运行机制就能有效地预防慢 SQL 或大查询堵塞或拖垮系统。

以上三点，源于 OceanBase 的架构设计以及在实践中的不断优化，这些是保证其高性能的关键因素。那么，为何 OceanBase 能在拥有更高性能的同时，还能实现更低的成本呢？

（六）OceanBase 选用成本

OceanBase 采用了 LSM-Tree 存储引擎，这一引擎同时支持编码压缩和通用压缩，因此具有极高的压缩比。根据我们的测试数据（见图 7），OceanBase 的集群存储空间相比 MySQL 可节省高达 75%，从而实现了更低的成本。

图 7 OceanBase 与 MySQL 表空间与集群总存储空间测试数据

随着多点 DMALL 服务业务的快速发展，数据量急剧增加，节点数也呈现指数级增长。在这种情况下，MySQL 的成本很快就会超过 OceanBase。我们在真实生产环境中得到的测试数据显示，OceanBase 的压缩比高达 6 倍（见图 8）。未来，随着业务数据的持续增长，OceanBase 可以不断地添加新节点，而其存储成本的增长速度将远远慢于 MySQL。

图 8 OceanBase 与 MySQL 成本测试数据

三、多点 DMALL 应用 OceanBase 的实践

（一）OceanBase 在多点 DMALL 业务场景中的优势

总结而言，OceanBase 数据库主要有四大优势。

(1) 存储成本更低。OceanBase 之所以存储成本更低，是因为它不仅采用了通用的压缩算法，还应用了先进的数据编码技术。根据我们的实践经验，将 MySQL 数据库迁移至 OceanBase 后，单副本的压缩率可接近 90%，这一数据表现极为出色。

(2) 混合部署更稳定。OceanBase 之所以在混合部署方面表现更稳定，是因为它不仅能实现租户间的资源隔离，还能在租户内部进一步设置隔离措施，有效限制用户或库级别的 I/O 和 CPU 消耗，从而确保系统的稳定运行。

(3) 兼具低延迟和高并发的特性。OceanBase 之所以能同时支持低延迟和高并发，其中一个重要原因是其可配置 Primary Zone 的功能。通过将主副本集中在一个 OBServer 节点上进行读写操作，类似于单机 MySQL 的读写模式，从而能够提供更低的延迟和更优的性能。而当需要应对高并发场景时，OceanBase 可以灵活配置副本在多个 Server 节点间进行负载均衡，以支持更高的并发量。

(4) 周边工具更加完善。我们广泛利用多台服务器的 I/O 和 CPU 资源，其中 OCP 管理平台发挥了至关重要的作用。OCP 管理平台集成了监控告警、备份恢复等丰富功能，无论是常见的还是复杂的需求，都能一应俱全地满足。在问题排查过程中，它提供的 Top SQL、Slow SQL 和可疑 SQL 分析功能尤为实用。此外，OMS 数据同步功能也非常强大，支持将多种数据源的数据轻松同步至我们的 OceanBase 数据库。

（二）从 MySQL 到 OceanBase 的迁移实践

截至目前，我们已在 OceanBase 上成功部署了五个业务库，总数据量达到 20TB。这些业务对商家至关重要，特别是对于大型客户而言，他们的仓库与门店紧密相连，需要 24 小时不间断运营，包括凌晨时段。这些只是当前的部分应用场景，未来我们将继续扩大 OceanBase 的应用范围，将更多业务迁移到 OceanBase 平台上。

(1) 存储成本收益显著。当我们将业务从 MySQL 迁移到 OceanBase 时，MySQL 中原本 2.1TB 的单副本数据量，在 OceanBase 中锐减至 252GB。这一显著变化得益于 OceanBase 的通用压缩和数据编码技术，使得压缩率接近惊人的 90%。考虑到 MySQL 采用一主两副本架构，而 OceanBase 采用三副本架构，综合计算下来，OceanBase 的整体压缩率为我们带来了超过 80%的成本节省。这不仅体现在存储成本上，还显著降低了运维成本。

(2) 运维更加便捷。首先，分布式数据库的扩展能力相比集中式数据库在运维上更为简单。对于 DBA 来说，维护并迁移一个 20TB 规模的数据库，在 MySQL 环境下至少需要 40 套每套 1TB 的 MySQL 实例，且迁移过程会有损，导致现有数据库连接全部中断，需要至少一名 DBA 全程参与。然而，在 OceanBase 中，由于其支持动态扩缩容和无损变更，我们只需扩容 OBServer 存储节点，并将域名解析到新的 OBProxy 上，即可实现无损迁移。此外，OceanBase 基于 Paxos 协议，确保了数据的强一致性和安全性。其次，借助可视化管控工具，运维工作更加便利。OCP 提供了备份、告警的可视化管理，以及良好的可观测性，包括 Top SQL、Slow SQL 的监控，并且原生支持高可用架构。为了确保管理的独立性和数据的清晰性，我们额外建立了一套与业务数据库分离的元数据数据库来支持 OCP 管理平台。

目前，OceanBase 中的 TPS 已达到近 1500，而 QPS 的最高值也接近 3000，表现出卓越的性能。

（三）OceanBase 的持续进化与未来展望

OceanBase 自 4.0 版本起，已支持单机与分布式一体化架构。4.2 版本正式引入了 OBKV Redis 支持，进一步丰富了其功能。而最新的 4.3 版本，更是新增了对向量化引擎和列存的支持，这一引擎正是构建 AI 大模型的重要基石。OceanBase 正不断进化，符合未来数据库的设想。

未来，我们将积极探索在更多业务场景中应用 OceanBase，包括将关系型 MySQL 与非关系型 Redis 数据库迁移到 OceanBase 平台。通过这一迁移，我们可以有效控制资源成本的持续增长，优化资源配置，进而直接提升利润空间。

四、OceanBase 在多租户架构下的资源隔离实践

（一）租户之间的资源隔离能力

OceanBase 的多租户架构在 CPU、内存、I/O 等资源上实现了物理级别的隔离。这一特性至关重要，它确保了不同租户之间的业务不会因资源争抢而相互影响，从而避免了因单个业务的问题而波及到其他租户的风险。

（二）租户的快速弹性伸缩能力

在 OceanBase 中，租户的扩容操作极为便捷。以拥有 3 个 Zone、每个 Zone 包含 2 台机器（共 6 台机器）、每台机器含有 1 个资源单元的租户为例，若需进行水平扩容，仅需执行一条 SQL 语句，即可轻松添加 Zone 4 和 Zone 5，使资源单元从 6 个增加至 10 个。同样，垂直扩容也简单易行，如初期配置的资源为 2C8G，随着业务增长，若不想增加机器，只需将资源单元从 2C8G 升级为 6C12G。这些扩容操作都是动态且无损的，业务运行完全不受影响。对于 DBA 而言，整个扩容过程仅需一条 SQL 语句即可完成，极大地减轻了工作量。因此，OceanBase 的多租户能力完美契合了 SaaS 场景下的需求，既节省了成本，又方便了后期的扩容操作。

五、总结

在面对零售 SaaS 场景下的诸多挑战时，我们选择了 OceanBase 数据库作为解决方案。OceanBase 凭借其分布式架构、高扩展性、低运维成本、高可用性以及优秀的存储压缩能力等优势，成功帮助我们实现了租户间资源的完全隔离与低成本系统升级。通过从 MySQL 到 OceanBase 的迁移实践，我们不仅大幅降低了存储成本和运维成本，还提高了系统的稳定性和性能。同时，OceanBase 在多租户架构下的资源隔离实践的应用，为我们的未来发展提供了有力的支撑。随着技术的不断发展，我们将继续与 OceanBase 携手共进，推动新零售行业的数字化转型和升级。

最后为大家推荐这个 OceanBase 开源负责人老纪的公众号「老纪的技术唠嗑局」，会持续更新和 #数据库、#AI、#技术架构 相关的各种技术内容。欢迎感兴趣的朋友们关注！

「老纪的技术唠嗑局」不仅希望能持续给大家带来有价值的技术分享，也希望能和大家一起为开源社区贡献一份力量。如果你对 OceanBase 开源社区认可，点亮一颗小星星✨吧！你的每一个 Star，都是我们努力的动力。