Skip to main content

场景介绍

关键字:资源池化 | 可管理性 | 降低成本

OceanBase 的原生多租户架构,支持一个集群中同时运行多个数据库租户,每个租户可以视为一个独立的数据库服务。租户间数据和资源互相隔离,并且在集群内统一调度。支持在创建租户时选择不同的兼容模式,每个租户可单独配置数据副本数量、副本类型、存储位置及计算资源等。

SaaS 资源整合场景

微服务架构

随着企业内业务系统越来越复杂,原来的单体服务在工程和管理上变的越来越不堪重负。使用微服务架构,新增和调整功能只需要增加新的微服务节点。但是每个微服务需要使用不同的数据库,数据库的数量大大增加,可靠性和运维管理都带来了挑战。

通过 OceanBase 多租户特性,管理员只需要运维少量集群,既能保证租户之间数据和资源互相隔离,又提升了数据库的稳定性。

多租户 SaaS 服务

云上的 SaaS 服务商,往往提供的是多租户的服务。多个业务租户的数据库如果在一个单机数据库中做逻辑名字空间隔离,大小租户之间互相影响。如果每个业务租户使用一个独立的数据库,成本高,几十到上百套分散数据库环境,运维工作复杂,同时扩展性受限。

通过 OceanBase 数据库内原生多租户的特性,能够更好地平衡隔离性和成本,而且大小租户可以独立进行扩缩容。

行业现状与挑战

  • 实例碎片化:企业内部多个不同业务应用,或 SaaS 企业面向不同客户的资源隔离需求,会导致需要部署大量的数据库实例,造成严重的碎片化,在某个关键业务或关键客户需求激增时,难以灵活的弹性扩展,性能和可用性难以保证。

  • 资源浪费:由于数据库资源的碎片化部署,单个实例为了保证一定的性能弹性空间,往往会多划出一部分容量作为短时间内请求增长的预备资源。这种资源预留在整体业务视角来看实际上造成了巨大的资源浪费,抬高了企业资源成本。

  • 管理复杂:大量的数据库实例同时带来的还有管理效率的降低, 数据库相关团队难以对成百甚至上千的实例进行精细化管理, 出现故障、抖动等事件时恢复时效差,对整体资源水位的把控难以全局掌控,抬高了企业的人力管理成本。

解决方案

基于 OceanBase 的多租户架构,帮助企业将多个不同业务的数据库实例集中整合,提升资源利用率,同时基于 Paxos 的多副本机制可以保证每个资源单元的高可用能力。

既适用于中大型企业内部大量不同业务链路的资源池化,也适用于各个行业 SaaS 服务商,为不同客户提供不同规格的实例,保证资源隔离性的同时降低成本。

image

方案优势

  • 多租户池化: OceanBase 集群原生实现了多租户下的资源隔离和虚拟化,一个集群中可以部署上百个数据库实例,每个实例数据和资源隔离,计算资源原地升配秒级生效。
  • 多维度弹性:基于 OceanBase 的多节点分布式架构,用户可以实现单机原地升配、多机弹性扩展,多机流量均衡多个维度的扩容操作,并且扩容对上层应用透明。对于涉及数据迁移的扩展无需人工值守,OceanBase 自动完成迁移以及多维度数据校验。
  • 统一管理:将多个零散的实例统一部署在 OceanBase 后,运维管理的复杂度大大降低,DBA 从之前管理几百个分散实例,到目前管理几个 OceanBase 集群,负载、告警、调优全部统一至集群级别,常规故障能够自动恢复,大幅提升业务支撑效率和应急响应能力。
  • 降本增效:不但通过多租户实现计算资源池化,提高总体利用率,OceanBase 的高级压缩能力使得存储成本仅为原来传统数据库的 1/3。经过大量的客户反馈和广泛案例实践统计,OceanBase 的资源整合方案能够帮助中型及以上企业降低 TCO 约 30%-50%。

用户案例

多点 DMALL(典型用户案例)

业务挑战

多点 DMALL 服务对象横跨国内、海外等众多零售商,在国内有物美、中百等大型商超,覆盖麦德龙、Seven Eleven 711 便利店等跨国零售商。同时,还为众多海内外品牌商提供服务,让品牌商、供应商、零售商能够链接起来,让数据和信息更好地流动,让服务对象能够更好地支撑服务 C 端用户。从生产商、品牌商、供应商,再到各个商场门店的零售商,最后到消费者,不难想象,超长的服务链路会产生超级庞大的数据量,系统的复杂度也将随着数据量呈指数级增长。在此背景下,多点零售 SaaS 系统数据库面临三大难题:

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

解决方案

  • OceanBase 的大集群模式,将多个单实例整合到 OceanBase 集群中,进行统一管理,灵活调度,有效提高资源利用率。
  • 使用租户进行资源隔离,多个业务模块之间数据独立,按需透明升降配。
  • 通过 OceanBase 强大的智能管控平台,典型问题自动分析和感知,运维效率大幅提升。
  • 借助 OMS ,在不停机的情况下全站业务向 OceanBase 实现高效快捷的迁移,业务仅需极少改造甚至零改造。
  • 通过 OceanBase 集群强大丰富的 Leader 分布和读写路由策略,将蚂蚁集团多年沉淀的高并发最佳实践输出给用户。

image

用户收益

  • 基于大集群多租户,实现秒级的数据库实例资源扩缩容,在整体集群资源使用不变的前提下,稳定承载大量业务的高峰压力。
  • 在解决了业务扩展性难题的同时,也大大降低了 DBA 的运维成本以及出错概率。在机房级容灾方面,实现 RPO = 0,RTO < 8s,稳定支撑多点上亿级的用户量。
  • 基于 OceanBase 的高级压缩技术,在保证性能的同时,多点的数据存储空间相比原先节约了近 6 倍。同等硬件投入的前提下,可存储更多数据。
  • OceanBase 高度兼容 MySQL 的 SQL、存储过程及触发器等高级特性,对传统数据库具备高兼容能力,让多点可以平稳、平滑迁移过往数据,保证在过渡时期的大量业务不受影响。

其他用户案例

  • 翼支付:https://open.oceanbase.com/blog/4446837760
    • 行业:政企 / 运营商
    • 痛点:由于在某国产数据库集群中放置了很多库,因此多个库之间共享集群资源,在某些库对应的业务流量高峰期时,业务之间互相影响,严重影响使用体验。
    • 收益:多租户能力及资源隔离优势明显。在实际使用中的商城业务会分很多库,为了避免这些库之间资源发生争抢从而导致其他库无法正常运行,将库按租户进行分离,利用租户的资源隔离能力,限制每个库的使用资源额度。并且,租户资源可以灵活调整,所以,每个库的资源也可以动态调整,从而保证业务的稳定性和灵活性。
  • 中国联通:https://open.oceanbase.com/blog/8185228352
    • 行业:政企 / 运营商
    • 痛点:几十到上百套分散数据库环境,运维工作复杂,同时扩展性受限。
    • 收益:一个 OceanBase 集群内同时运行多个数据库租户,每个租户可以视为一个独立的数据库服务;租户间数据和资源互相隔离,并且在集群内统一调度。
  • 好未来:https://open.oceanbase.com/blog/7832546560
    • 行业:教育
    • 痛点:单机多实例方式部署,缺少资源的隔离能力,会产生大量的资源碎片。资源部署模式不具备可弹扩能力,资源在分配时会留有较大的冗余,导致资源利用率低。
    • 收益:多租户,实现资源隔离及资源弹扩。数据压缩,获得额外的成本收益。
  • 阳光保险:https://open.oceanbase.com/blog/8657676560
    • 行业:金融
    • 痛点:很多小型业务搭载在 MySQL 上的运维复杂问题
    • 收益:通过多租户实现资源隔离。根据业务情况设置资源规则,使机器资源得到充分利用。
  • 厦门科拓通讯:https://open.oceanbase.com/blog/7521893152
    • 行业:物流与出行
    • 痛点:基于 MySQL,无法实现整个平台 SaaS 架构的升级。每个集团都是独立的,数据没有交互,部分集团也有数据隔离这样的需求,SaaS 化后能减轻部分私有化部署和后期运维的成本。
    • 收益:使用 OceanBase 之后,简化了私有化的部署和运营。根据集团的规模,选择不同规格的租户,能够更加清晰地计算每个集团使用的资源和费用预估。进行资源隔离后,每个集团的数据体量相对所有集团聚合到一起会更小,系统就能拥有更好的性能、稳定性、扩展性。
Loading...