OceanBase为客户提供全生命周期的数据库解决方案，从迁移评估、架构设计、迁移上线的数据库核心系统升级解决方案，到数据融合汇聚、数据实时分析的大数据解决方案，再到深入电商大促、跨云部署等具体场景的解决方案，现已助力金融、政府、运营商、零售、互联网等多个行业的多家客户实现数据库升级和改造。下面将基于几个核心业务场景来进行说明。
交易支付场景
交易支付系统是每个公司最核心的一个业务场景，数据存取通常采用分库分表方案，虽然带来了水平扩展和灰度升级的能力，但也出现了单机容量不足的问题。为了解决这个问题，业务需要将数据拆分成更多的份，这不仅耗时耗力，而且技术风险很高。
OceanBase数据库利用分区表的方案解决了这个问题。通过将原来的每份数据打散为多个数据分区，利用分区表打破单机的容量限制，从数据层完成拆分过程，无需业务改造，极大地节省了成本，降低了技术风险。同时，OceanBase数据库的分区表方案也可以使得用户完全无需关注数据的分布细节，轻松支持跨分区的分布式事务、多分区的关联，真正实现"透明"访问分布式数据库。
比如支付宝对上层业务进行了单元化改造，并以分库分表为架构基础。在交易支付核心库上，采用了按照UID进行分表存储的方式，利用OceanBase的单表多Partition架构实现大规模分表。业务请求数据时，通过中间件计算分区ID并由OBProxy路由到正确存储节点，实现了稳定支撑每秒百万笔支付请求的能力。此外，引入了Table Group，将使用相同分区的一组逻辑表聚集在同一OceanBase节点上，将分布式事务转化为单机事务，提升了性能并降低了跨机器操作成本。支付宝平稳支撑10年“双11”的情况如图所示：
HTAP场景
随着业务规模扩大和数据量增长，业务系统增多且逻辑复杂，传统在线数据库需要进行拆分，但拆分后的架构无法满足一些需要进行关联统计和实时分析的需求。此时，类实时数仓产品应运而生。但并非所有企业都必须构建一整套生态链路。OceanBase的HTAP模式通过使用一套引擎，支持高并发在线吞吐的同时，提供海量数据的实时在线分析能力，为企业提升效率、持续创新提供澎湃动力。OceanBase的无共享MPP架构具有很好的资源隔离机制。这种架构最大程度地保持了数据的新鲜度，省去了许多业务场景中实时数仓的构建工作，帮助客户实现业务价值。
比如邮储银行采用OceanBase一套引擎处理 OLTP 和基本的 OLAP 场景，同时基于资源组隔离技术，提供 OLTP/OLAP 业务资源隔离的可靠方案，免去复杂的实时数仓建设，并且利用强大的并行执行引擎和 SQL 优化器，支持银行海量数据的并行计算分析，实现了网点运营平台的一体化实时分析，为银行业务决策提供了有利保障。OceanBase HTAP方案如图所示。
邮储银行采用OceanBase一套引擎处理OLTP 和基本的 OLAP 场景，提供 OLTP/OLAP 业务资源隔离的可靠方案，免去复杂的实时数仓建设，并且利用强大的并行执行引擎和 SQL 优化器，支持银行海量数据的并行计算分析，实现了网点运营平台的一体化实时分析，为银行业务决策提供了有利保障。
资源隔离场景
OceanBase数据库通过租户实现资源隔离，保证每个数据库服务实例不感知其他实例的存在，并通过权限控制确保租户数据的安全性。它具备强大的可扩展性，可以提供安全、灵活的DBaaS（数据库即服务）服务。多租户特性更适用于SaaS（软件即服务）场景，因为它能够提供租户间的资源隔离和库容弹性伸缩能力。OceanBase实现了从CPU、内存和I/O等方面对租户进行物理隔离，这确保了业务之间不会发生资源争抢或相互影响，避免一个业务影响其他租户的情况发生。
多租户能力可以快速弹性伸缩来解决SaaS场景中的部署和扩容需求：通过增加Zone和变更资源单元，多租户能力使DBA能够轻松水平和垂直扩展资源，而业务对此无感知。这降低了DBA的工作量，并满足SaaS场景对部署一套系统以节省成本和方便后期扩容的需求。
在OceanBase数据库中，租户是资源分配的单位，是数据库对象管理和资源管理的基础。租户在一定程度上类似于传统数据库中的"实例"概念，并且彼此完全隔离。为了数据安全，OceanBase数据库禁止跨租户的数据访问，以保证用户的数据不会被其他租户访问和窃取。在资源使用方面，每个租户独占其资源配额。综上所述，租户在OceanBase数据库中既是各种数据库对象的容器，也是资源（如CPU、内存、IO等）的容器。下图是OceanBase的多租户能力体现：
比如翼支付多租户方案在上线验证后，性能方面较旧方案提升 5 倍，机器成本与运维成本极大降低。于是决定将消息中心、账单中心等业务由某国产数据库替换成 OceanBase ，同时将已有的 MySQL 业务逐渐迁移至新方案。其中存储空间利用率显著下降，相较于原本使用的MySQL，翼支付在使用OceanBase后，所需的存储空间大幅减少到只有17T，减少了超过76%，使得存储成本显著降低。并且CPU资源平均使用率明显下降，在翼支付原本的MySQL环境下，CPU资源的平均使用率为20%-25%，而切换到OceanBase后，CPU资源的平均使用率下降到10%，降低了40%-50%。
异地多活场景
随着数据量和并发访问量的快速增长，城市级别的容灾能力成为关键业务的重要需求，以支持多种应用系统的管理与使用。OceanBase凭借在蚂蚁集团和网商银行多年的真实场景经验，沉淀出了基于“三地五中心”的数据库异地多活架构，为对数据一致性和系统可用性要求极其严苛的核心关键系统提供了领先业界的标杆案例。
比如蚂蚁网商银行的“三地五中心”架构，建立了城市级故障自动容灾能力。该架构完全依赖数据库内部机制建立的城市级故障自动容灾系统，并且应用在金融领域的核心业务上，具有重要的标志性的意义，下图11-2是网商银行“三地五中心”架构图。
网商银行为了解决业务服务层的容灾采用了云单元架构，为了解决数据存储层的容灾问题使用了OceanBase产品，OceanBase实现了异地多活，彻底解决了数据层的容灾问题，达到了银行业最高容灾等级标准要求，RPO为零、RTO为数分钟。同时，采用三地五中心部署实现异地容灾，实现了核心交易流量部署在所有数据中心并可随时切换和调配，提升了系统面对城市级故障的处理能力。读写分离+异地多活，实现了流量在全国范围内的任意调拨，极大地提高了资源利用率和业务系统吞吐量。日常运营维护100%白屏化，降低了维护运营成本。
总结
本文的场景和图片是基于OceanBase官网的总结，目的是为了让大家了解OceanBase的场景，大家基于“合适的场景合适的DB”选择自己搞得定且产品力强大的分布式数据库。
