存储空间压缩6倍 ，多点DMALL零售SaaS场景降本实践

多点 DMALL 作为中国及亚洲最大的零售云解决方案数字零售服务商，是中国唯一的端到端全渠道零售云解决方案服务商，目前，其业务据点覆盖六个国家和地区，商业模式受到广泛验证，其发展历程可以说是中国乃至世界零售数字化进程的缩影。

但在业务高速增长、成果光鲜亮丽的背后，多点 DMALL 也面临着诸多来自零售 SaaS 场景和业务系统瓶颈的挑战，本文针对零售 SaaS 场景数据处理的痛点，从业务视角出发，讲述多点 DMALL 如何在做到保障业务数据库稳定可靠的同时，还能兼顾更高的读写性能与更低的存储成本。

多点 DMALL 服务对象横跨国内、海外等众多零售商，在国内有物美、中百等大型商超，覆盖麦德龙、Seven Eleven 711 便利店等跨国零售商。同时，还为众多海内外品牌商提供服务，让品牌商、供应商、零售商能够链接起来，让数据和信息更好地流动，让服务对象能够更好地支撑服务 C 端用户。

从生产商、品牌商、供应商，再到各个商场门店的零售商，最后到消费者，不难想象，超长的服务链路会产生超级庞大的数据量，系统的复杂度也将随着数据量呈指数级增长。在此背景下，多点零售 SaaS 系统数据库面临三大难题：

第一，运维复杂度高。多点 DMALL 使用微服务架构，全流程业务环节多，系统应用规模大，对应数据库的数量超过了 500 个。且随着系统不断迭代，数据的规模还在持续增加，运维管理难度越来越大。

第二，业务增长快，水平扩展需求增多。随着业务的增长，我们制定了出海战略，需要在海外展开业务，基于地区数据安全法的要求，需要独立部署一整套全新的系统去承接海外业务流量。在初始的部署阶段，对后期业务规模及数据增长速度是难以准确预估的。因此，数据库资源在初始阶段的分配就变得十分困难。为了节约成本，常见的做法是给到较少的部署资源。但很快我们发现，业务的快速增长，数据的增长特别迅猛，带给我们的是如何快速扩容这一难题。

第三，需要在同一个集群中服务大量商家。便利店/连锁商超的 SKU（最小存货单位）规模，从几千到几万，我们很难做到给每个商家独立部署一套系统。因此，我们 SaaS 系统支持上百个中小商家客户，所有商家产生的数据，在底层共享数据库资源。还有一个显著特点，在我们系统中存在非常大的单个租户，比如大型连锁商超，我们希望能让大型连锁商超所在的租户与其他租户有一定的资源隔离。

综上，我们希望数据库能够支撑庞大数据规模，还能应对数据快速增长。

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

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

首先，从扩展性考虑，我们有很多 MySQL 单库数据量超过了 4TB，并且还在快速增长。我们将最大 MySQL 切换到分布式数据库后，数据增长到了 29TB。对于数据快速增长及面临的 MySQL 容量瓶颈，DBA 非常担忧：

• 要么我们不断推动研发清理数据，做数据归档，然而结果往往很被动，因为研发的重点工作是业务需求迭代；

• 要么继续扩展磁盘，如果是在云上，扩展空间比较容易，云厂商提供的块存储单盘可以达到 32TB 甚至更大，但数据继续增长，仅仅是将风险延后, 治标不治本, 后续会更加被动。

当然，我们还可以选择分库分表的方案，但这是一件操作繁琐、风险很高的事情，且需要耗时数月，因为 SQL 能力有损，代码改造不可避免。

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

首先，从运维成本考虑，在保证系统稳定性前提下，降低运维复杂度。假设 MySQL 中的一个 database 是一颗蛋，一个 MySQL 实例是一个篮子，那么部署 1000 个 database，应该放到多少 MySQL 实例中？把哪些库放在同一个实例中？如果把两个对资源要求都很高的重要库放在同一个实例中，就有可能会互相抢占资源。还有，例如支付类的数据量虽然不大，但对业务的要求很高，也不能和其他库放在同一个实例中。

因为业务不同，优先级不同，数据增长速度不同，QPS 要求不同，所以 DBA 常常需要 “挪蛋”。哪怕抛开资源成本不谈，本身的运维挑战就很大，我们希望分布式数据库可以解决这个问题，帮助 DBA 去自动 “挪蛋”。

其次，从高可用考虑，期望保证集群高可用能力。运维 MySQL 集群，我们基本都是使用 MHA、Orchestrator 去实现高可用，但他们都是“外挂”形式的，本质上是解决不了网络分区导致的脑裂问题，因为数据库和 HA 组件之间，是两个独立的软件，不在同一个进程里，他们之间没有一致性协同控制。

对于 MySQL，Group Replication 这类高可用架构，其内置实现的高可用是可靠的，它与 OceanBase 或者 TiDB 等分布式数据库一样，是基于Paxos 或者 Raft 分布式一致性协议，可以实现 RPO=0，RTO<30s。

（二）产品选型测试数据

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

在 OceanBase 与 MySQL 配置相同的情况下，对比 10 张 3 千万 sysbench，我们发现当并发数小于 200 的时候，MySQL 的表现略好于 OceanBase。但无论是 QPS 还是延迟，随着并发数的上涨，OceanBase 的性能都会逐渐接近 MySQL。

（三）OceanBase 不同配置的对比

对于单机部署的模式，选择通过连接 OBProxy 访问 OBServer 还是直接 OBServer，也会影响其在 10 张 3 千万 Sysbench 表读写 QPS 的表现。

我们来看选择连接 OBProxy 和选择直连 OBServer 时的表现，可以看到直连 OBServer 性能比通过 OBProxy 连接的性能高 30-50%。

所以对于单机部署的模式来说，我们建议直接 OBServer，避免通过 OBProxy 访问 OBServer 多走一次网络带来的额外代价。

在不同租户内存配置下，性能也会有所不同。可以看到 32GB 租户内存相比 16GB 租户内存，性能提升约 14%。

（四）OceanBase 与 MySQL 表空间对比

在生产环境监控快照场景，将 20 张表共 5 亿数据量从 MySQL 迁移 OceanBase，表空间占用降低 6 倍。 

基于上述测试数据，我们最终决定上线 OceanBase，总的来说：

• 生产环境监控快照场景 MySQL 存储（单副本）对比 OceanBase 存储（单副本），数据压缩率为 6:1，OceanBase 的数据压缩比优秀；

• 单机部署并且连接 obproxy，在并发度较低时，OceanBase QPS 和平均延迟表现稍逊 MySQL（最低 QPS 也过万，租户内存越高 QPS 性能越好；最低平均延迟 3ms）。在并发度逐渐上升的过程中，OceanBase 各项性能的提升比例会高于 MySQL（当并发度超过 200 之后，OceanBase 各项性能会逼近甚至超过 MySQL）；

• MySQL 一层架构、OceanBase 二层架构（obproxy + observer，单机部署时直连 observer 比连 obproxy 性能会提升 30%~50%）。每多一层，网络层面的延迟消耗会增加。

第一，OceanBase 是单机分布式一体化数据库。从两个方面来讲：单机是指性能可以像 MySQL 单机一样做到低延迟、高性能；分布式是指当我们需要去规模化扩容时可以轻松扩展。那这两个特性可以帮我们解决什么问题呢？

从业务发展阶段及价值来看，在业务初期，数据量较小，享受 MySQL 般极致性能；在业务高速增长期，可以透明扩展，几乎不限容量；在业务的全生命周期里，可以轻松做到不改代码、不停机迁移，并保证高性能。

第二，OceanBase 作为原生的分布式数据库，天然具备分片自动迁移、负载均衡的可扩展能力，可以在业务无感知的情况下透明扩缩容。基于 Paxos 协议的极致追求，OceanBase 4.x 版本进一步的极致优化，可以做到 RPO=0，RTO<8s，保证系统高可用。

第三，OceanBase 通过最小化分布式开销的架构设计保证数据库高性能，而 OceanBase 的高压缩比相对 MySQL 节省成本6倍以上。同时 OceanBase 多租户十分契合 SaaS 客户的业务场景，资源隔离、扩缩容非常容易。

分布式数据库的数据处理涉及内存、磁盘、网络交互，在延迟方面，内存中读写数据在 0.1 微秒级别，SSD 延迟约为 0.1 毫秒，机房内网络延迟约为 0.1 毫秒，同城机房间延迟约 3 毫秒。整体来看，内存的读写延迟与 SSD、网络之间，相差了 100-1000 倍；吞吐方面，内存读写可达到 100GB/s，而 SSD 约为 1～2 GB/s，万兆网络约为 1.2GB/s，内存与 SSD、网络之间，吞吐能力相差约 100 倍，差了两个数量级。

MySQL 作为单机数据库，InnoDB 和 Server 层是在同一进程中，数据交互非常高效，在性能和延迟方面，基本是无敌的。但对于分布式数据库来说，往往采用了计算存储分离架构，由于计算和存储层之间网络 I/O 开销不可避免，这种设计上就带来的性能瓶颈很难被优化。

OceanBase 的架构设计独特之处就是 SQL引擎，存储引擎，事务引擎实现在一个进程里，OBServer 既做计算又做存储。应用通过 OBProxy 连接 OBServer 集群，OBSever 节点会把数据路由信息上报给 OBProxy，OBProxy 在接收到应用层 SQL后，根据路由信息，直接转发 SQL 到最合适的 OBSever 上去执行。如果数据都在 1 个 OBServer 节点上，那么 SQL 执行过程就是单机的，类似于 MySQL，最大程度减少了网络 I/O 。

（一）为什么 OceanBase 性能更好

当数据量大时或者更高并发时, OceanBase 性能明显优于MySQL, 于是我们对OceanBase 架构进行深入研究。

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

第二，通过 Table group 优化跨机 join，可以将跨机事务优化成单机事务。分区粒度的设计，可以保证 80% 的事务是单机的，再通过 Table group 机制优化高频的跨机 join 后，单机事务占比可以进一步提升，如果整个业务中有 90% 以上的事务都是单机事务，性能肯定会很好。

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

以上三点，来自于架构设计，以及实践中的优化，是保证 OceanBase 高性能的原因。那么，为什么 OceanBase 能够在拥有更高性能的同时，成本却更低呢？

（二）为什么 OceanBase 成本更低？

OceanBase 使用 LSM-Tree 存储引擎，同时支持编码压缩和通用压缩，具有高压缩比，根据我们的测试数据（见下图）可看出集群存储空间相比 MySQL节省 75%，成本更低。

随着多点 DMALL 业务的发展，数据量激增，节点数也在呈指数级变化，眼看着MySQL 的成本很快将超过 OceanBase。如下图所示，6 倍压缩是我们在真实生产环境中得到的测试结论。未来业务数据一直增长，OceanBase 可以不停地加新的节点，而对应的存储成本的增长却是远远慢于 MySQL的。

（三）OceanBase 的多租户和资源隔离能力

OceanBase 的多租户特性更契合 SaaS 场景，从租户间的资源隔离能力与租户的弹性伸缩能力可见一斑。

• 租户之间的资源隔离能力：OceanBase 的多租户是从CPU、 内存、I/O 上进行物理隔离，这非常关键，保证了业务之间不会出现资源争抢，相互影响，不会因为一个业务而影响其他的租户。

• 租户的快速弹性伸缩能力：对于一个租户而言，假设有 3 个 Zone,每个 Zone 有 2 台机器，一共 6 台机器，每台机器 有 1 个资源单元。如果想去扩容，只需要一条 SQL语句，就可以加上 Zone 4、加上 Zone 5，变成更多的 Zone，从 6 个资源单元变成了 10 个，轻松完成水平扩容。同时垂直类的扩容也很简单，比如初期给定的资源是 2C8G，业务增长后，又不想加机器，可以把资源单元从 2C8G 变更为 6C12G，整个过程是动态无损的，业务无感知。这对 DBA 来讲也是一条 SQL 就能搞定，极大降低了工作量。因此，多租户能力很好地解决了 SaaS 场景需要部署一套系统，想要节省成本且方便后期扩容的需求。

多点 DMALL作为 SaaS 场景服务商，本身面临着数据库多、数据增速快、资源成本高、运维难度大等诸多痛点。分布式数据库可以很好地支撑业务增长，提升开发效率，解放 DBA，是未来数据库转型坚定的方向。经过探索测试，验证了 OceanBase 在扩展性、性能、成本方面的优势，符合当前业务发展的需求，且多租户能力方面与零售 SaaS 场景非常契合，后续必定会有更加深入的合作。

文章转载自公众号：OceanBase