本文来自OceanBase的客户，百丽时尚的使用和测试分享

业务背景

百丽时尚集团，作为国内大型时尚鞋服集团，在中国超过300个城市设有直营门店，数量超过9,000家。集团构建了以消费者需求为核心的垂直一体化业务模式，涵盖了从时尚趋势研究、商品规划、设计创新、生产制造、商品管理、DTC零售到客户服务的整个价值链。在这一过程中，每个环节都充分运用数字化技术，以优化业务流程并提升效率。未来，集团还将继续加大科技投入，推动业务的持续创新和升级。

目前，零售、电商以及私域流量等业务线涉及在线订单和商品调度等，业务系统的技术架构使用MySQL+MyCAT的分库分表的架构，并使用orchestrator作为高可用的管理中间件。由于MyCAT架构下存在不支持分布式事务、分片业务调整困难和可扩展性差等问题，因此开始考虑使用分布式数据库，自2023年初测试OceanBase以来，发现其在分布式事务，分布式查询优化、水平可扩展性和周边工具生态方面表现优异，能够精准解决我们之前的痛点并且减少运维难度和成本。本文分享百丽测试和使用OceanBase4.2版本的感受。

一、MyCAT 使用痛点及解决方案

1. 聚合性能不稳定。

百丽时尚此前使用MyCAT+MySQL的分库分表架构，MyCAT作为分布式中间件在聚合查询场景的性能，尤其在多个分片的数据聚合方面的性能容易抖动。使用OceanBase后，其作为原生分布式数据库从根本上避免了这类问题。例如，在我们生产环境的一些真实查询场景中，MySQL需要10分钟以上，在OceanBase只需要1分钟左右，性能提升了10倍左右。

2. 数据分片调整困难。

在一些日常运维的过程中，我们会有业务要调整，而MySQL的分库分表架构调整起来非常困难。一方面会涉及数据的重分布，另一方面是DBA实操的复杂度较高且非常繁重。但是如果在OceanBase中，我们只需要调整表分区，OceanBase会自动对分区做重分布操作，操作非常简洁、讯速，极大地减少了DBA的整体工作量。

3.水平扩容较差。

集中式数据库的水平扩容无法满足不断增长的数据处理需求。而在OceanBase中，我们可以根据业务的实际需求和实际情况，有选择性的做水平扩容或垂直扩容，非常灵活。比如可以水平做租户资源，或者在集群级别添加OBServer节点；再比如扩容磁盘，我们数据盘的使用率较高，对磁盘扩容后，数据文件也会自动扩展。

二、原生分布式数据库方案的特点

从集中式数据库替换为分布式数据库，从MySQL分库分表架构替换为OceanBase单机分布式一体化架构，也让我们对新型分布式数据库的特点有了更加深入的理解，具体而言包括以下五点。

1.原生分布式事务的支持：通过2PC协议，保障事务一致性。

众所周知MyCAT不支持分布式事务，在一些极端场景下可能出现事务问题，比如1PC阶段这个事务成功了，但在2PC阶段事务失败了。OceanBase的高可用选举和日志同步协议基于Paxos一致性协议，任何决策的达成均需要多数派节点达成一致，实现了原生支持分布式事务，保证事务的一致性。

2.数据复制和冗余。

在MySQL中，需要部署一些主从节点来增加它的数据冗余，提高数据高可用，但这样做会增加一些运维成本。那么在OceanBase中是如何实现的呢？为了提高数据的可用性和容错性，分布式数据库通常采用数据复制和冗余策略。数据复制可以将数据副本存储在多个节点上，以防单点故障。例如在一个3节点的OceanBase集群中，数据有三个副本，每个 OBServer 存放一份，每个OBServer内都有一份完整的数据。保证单节点宕机的数据可靠性，实现RPO=0。

3.数据一致性和同步。

分布式数据库需要确保数据在不同节点间的同步和一致性。常用的方法包括分布式事务和数据复制机制，以保证数据的一致性和可靠性。我们使用MyCAT的时候，其实每个分片的数据是不一致的，此时无法保证数据一致性。而在OceanBase中，主从副本之间通过基于 Multi-Paxos 的分布式共识协议实现了副本之间数据的一致性。

4.分布式查询优化。 

由于数据存储在多个节点上，分布式数据库需要进行查询优化和查询路由，以最大程度地减少数据传输和查询延迟。关系数据表的数据以分区形式存放在系统的各个节点上，OceanBase 数据库的优化器会自动根据查询和数据的物理分布生成分布式执行计划。当单个查询的访问数据不在同一个节点上时，需要通过数据重分布的方式，相关数据执行分发到相同的节点进行计算，通过并发执行以提高执行效率。比如auto DOP会自动加一些并行。对于AP场景的业务来说，可以提高执行性能。

5.高可用性和容错性。

分布式数据库通常具有高可用性和容错性，即使某个节点发生故障，系统仍然可以继续提供服务。OceanBase每个节点都有一个数据的副本，在某一些节点发生故障的时候，它会自动做副本的切换。当主副本所在节点发生故障时，一个从副本会被选举为新的主副本并继续提供服务。反观我们使用的MyCAT，需要借助像australia这样的中间件，带来了额外的运维成本。

三、OceanBase4.x 使用体验

最后分享一下关于我们目前在使用OceanBase V4.2_CE版本的一些体验感受。

第一，在OceanBase 4.x版本中，底层引入了日志流，解决了我们之前在体验3.x版本节点分区数有最大限制的痛点。OceanBase 早期版本的架构体系里以分区为基本单元进行操作，当系统内的分区数量达到一定程度后，以分区为单元的操作的消耗也随之增大，因此，单节点支持的分区数量受到限制，单节点上涉及跨分区的数据修改也需要两阶段提交协议来保证事务的原子性等问题。4.x版本引入日志流之后，我们的某一些分区域都采用同一个日志流，减少Paxos组的设计，使每一个OBServer的分区数可以极大提高。

第二，OceanBase提供的工具极大地降低了运维复杂度。

部署方式非常便捷，包括OCP的图形化部署、OBD的白屏化部署等，极大地降低了部署和运维难度。

在一些常用的运维场景，比如OBServer上下线、备份恢复等操作均可使用图形化界面管理，不需要手动操作和编写脚本，或者在平台开发对应的逻辑。而且OCP的功能非常完善，基本考虑到了日常运维中的方方面面。例如，我们业务上有部分信息集成需求，OCP提供了非常丰富的API接口，我们能够想到的所有操作都可以通过这样的API接口完成，并与现有的运维体系对接。

OMS的迁移平滑。最近把我们的数据库管理平台从MySQL迁移到了OceanBase，整个链路从结构迁移、全量和增量数据迁移，到全量校验，再到反向增量迁移，都非常平滑，极大地降低了DBA在数据迁移过程中的工作量。

写在最后

由于OceanBase有原生高可用、水平扩展、低成本、实时HTAP等特点，百丽选择OceanBase替换MySQL。但在日常使用中，我们发现开发人员对分布式事务概念不明确，对分区和tablegroup概念不清晰等问题，仍然保留着集中式数据库的应用惯性。因此，在替换数据库时，需要运维、架构和相关开发人员共同参与，必要时可以对开发同事开展培训。