分布式架构重塑零售数字化运营底座

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

从生产商、品牌商、供应商，再到各个商场门店的零售商，最后到消费者，不难想象，超长的服务链路会产生超级庞大的数据量，系统的复杂度也将随着数据量呈指数级增长。

1. 运维复杂度高
   1. 多点 DMALL 使用微服务架构，全流程业务环节多，系统应用规模大，对应数据库的数量超过了 500 个。且随着系统不断迭代，数据的规模还在持续增加，运维管理难度越来越大。
2. 业务增长快
   1. 水平扩展需求增多。随着业务增的长，我们制定了出海战略，需要在海外展开业务，基于地区数据安全法的要求，需要独立部署一整套全新的系统去承接海外业务流量。在初始的部署阶段，对后期业务规模及数据增长速度是难以准确预估的。因此，数据库资源在初始阶段的分配就变得十分困难。为了节约成本，常见的做法是给到较少的部署资源。但很快我们发现，业务的快速增长，数据的增长特别迅猛，带给我们的是如何快速扩容这一难题。
3. 资源隔离难
   1. 需要在同一个集群中服务大量商家。便利店/连锁商超的 SKU（最小存货单位）规模，从几千到几万，我们很难做到给每个商家独立部署一套系统。因此，我们 SaaS 系统支持上百个中小商家客户，所有商家产生的数据，在底层共享数据库资源。还有一个显著特点，在我们系统中存在非常大的单个租户，比如大型连锁商超，我们希望能让大型连锁商超所在的租户与其他租户有一定的资源隔离。

1. 单机分布式一体化
   1. 单机是指性能可以像 MySQL 单机一样做到低延迟、高性能；分布式是指当我们需要去规模化扩容时可以轻松扩展。从业务发展阶段及价值来看，在业务初期，数据量较小，享受 MySQL 般极致性能；在业务高速增长期，可以透明扩展，几乎不限容量；在业务的全生命周期里，可以轻松做到不改代码、不停机迁移，并保证高性能。
2. 高级压缩技术
   1. OceanBase 使用 LSM-Tree 存储引擎，同时支持编码压缩和通用压缩，具有高压缩比，对海量数据的场景非常友好。
3. 多租户
   1. MySQL 数据库实例多，可以将多个实例放到一套OceanBase集群，通过多租户的能力将数据相互隔离，也支持创建 DBLink 来打通不同租户的数据访问，方便管理且降低运维成本。

经过探索测试，验证了 OceanBase 在扩展性、性能、成本方面的优势，符合当前业务发展的需求，且多租户能力方面与零售 SaaS 场景非常契合。

1. 成本显著降低
   1. ​生产环境监控快照场景，MySQL存储（单副本）对比OceanBase存储（单副本），数据压缩率为 6:1。根据测试数据，集群存储空间相比 MySQL节省 75% ，成本更低。
2. 单机各项性能逼近甚至超过 MySQL
   1. ​单机部署 OceanBase 时在并发度超过 200 之后，OceanBase 各项性能会逼近甚至超过 MySQL
3. SaaS 场景需求满足
   1. ​多租户能力很好地解决了 SaaS 场景需要部署一套系统，但要节省成本且方便后期扩容的需求。
      1. 租户之间的资源隔离，保证业务之间不会出现资源争抢、相互影响，不会因为一个业务而影响其他的租户。
         1. 租户的快速弹性伸缩，整个过程是动态无损的，业务无感知。DBA 一条 SQL 就能搞定，极大降低工作量。