欧派选择阿里云瑶池旗下的云原生数据库PolarDB PostgreSQL版（以下简称PolarDB-PG）最初是由于目前的上云趋势，感觉架构优秀、非常稳定，给了整个团队使用的信心。体验之后发现，PolarDB-PG云上运行体验比自建Oracle更容易扩缩容，云上运维比较专业，相比于我们自己运维响应快、解决问题效率高。
—— 欧派运维负责人
1. 客户介绍
1.1 关于欧派
欧派家居集团股份有限公司创立于1994年，是国内综合型的现代整体家居一体化服务供应商。欧派家居2022年的年营收达200多亿元，连续四年入选中国制造业民营企业500强，是国内龙头定制家居品牌商。
2015年，欧派全面启动“欧派制造2025”战略，融合互联网、大数据与人工智能制造，通过数字化打通销售、研发、生产制造、物流运输等全套环节，打造以MTDS终端设计营销服务管理系统、WCC智能拆单系统、MSCS生产调度控制系统、APS+XMES柔性生产制造管理系统、MCTS物流管理信息系统五大主干系统构成，全流程协同，实现自动化与智能化的智造系统。
1.2 核心系统
欧派的MSCS系统在整个生产和制造流程中发挥着核心作用。举个例子，当用户订购一个衣柜时，前端的设计软件会生成渲染图并传输到MSCS系统中。该系统将执行诸多操作，包括将整个产品拆解为多个板材、五金等组件。拆解完成后，还会进行技术审核、价格审核等一系列流程，最终把生成的子单元进行路由分配，交由生产系统执行生产的最后阶段。
MSCS系统的顺利运行对于整个系统的上游和下游有着至关重要的意义。MSCS系统上游是独立的客户订单，下游是不同的生产工厂，是整个生产系统能够顺利运转的核心中枢。
2. 欧派遇到的业务挑战
2.1 实时响应的挑战和巨大的业务压力
欧派家居在咨询、设计定制、生产调度、物流跟踪到售后服务，这一系列复杂的过程中，所涉及的数据量极为庞大，往往单个订单的更新就能触及数万条数据条目的变动。这不仅包括了客户基本信息、产品规格、材料库存、生产进度、成本核算等直接关联信息，还涵盖了市场趋势分析、消费者行为预测等间接影响因素。因此，如何高效、准确地处理这些海量数据，成为了决定企业运营效率与竞争力的关键所在。其中关键的指标是要求关键业务查询，如订单状态追踪、库存水平监控、生产进度同步等，能够在秒级别内完成响应。
从监控数据来看，数据库每秒进行的全表扫描操作涉及近一亿行记录，而每秒的数据插入和更新操作约3000行。这反映出该系统在日常运营中承受着相对较高的业务负荷。
2.2 密集更新导致的IO问题
▶︎ 2.2.1 磁盘I/O效率的挑战磁盘I/O效率直接关系到数据读写速度，是衡量系统响应能力和处理能力的关键指标。在TB级数据日常更新的情境下，考虑I/O调度算法、缓存策略（如LRU、ARC）以及RAID配置等多方面因素，以进一步优化I/O操作，减少访问延迟，确保数据能够高效、稳定地被处理和存储。
▶︎ 2.2.2 数据库垃圾回收的效率考量
在频繁的数据更新过程中，会产生大量的废弃数据块或记录，这不仅占用宝贵的存储空间，还会降低查询效率。高效的垃圾回收机制对于维持数据库性能至关重要。
▶︎ 2.2.3 表空间膨胀问题及其应对
随着数据量的持续累积，表空间膨胀成为一个不容忽视的问题。它不仅消耗存储资源，还可能导致索引效率下降、备份恢复时间延长等问题。
综上所述，面对TB级别日常数据更新的挑战，通过优化磁盘I/O效率、强化数据库垃圾回收机制，并采取有效的表空间管理策略，是确保数据处理系统高效、稳定运行的关键。
2.3 对Oracle生态的高度依赖
客户的系统架构选择Oracle作为其核心支撑平台。Oracle数据库凭借其高度可扩展性、强大的事务处理能力以及丰富的功能集，长期以来为客户提供稳定可靠的数据服务，支撑着复杂多变的业务场景。然而，随着技术生态的不断演进与企业需求的日益增长，探讨数据库迁移的话题不可避免地摆上了桌面。
▶︎ 2.3.1 业务调整的广度与深度
首先，数据库迁移不仅仅是数据本身从一个平台到另一个平台的物理转移，它触及的是整个IT生态系统的核心。由于Oracle数据库特有的SQL语法、高级特性（如分区表、独特的存储过程等）以及与Java EE应用服务器的紧密集成，迁移过程中可能需要对应用程序中的SQL语句进行重写或优化，以适应新的数据库系统。这一工作不仅耗时，还要求开发团队具备深厚的数据库知识和新目标系统的熟练掌握，增加了项目的时间成本和技术难度。
▶︎ 2.3.2 数据兼容性与完整性
数据是企业的生命线，确保迁移过程中数据的完整性和一致性是首要任务。不同数据库系统之间在数据类型支持、存储机制乃至索引策略上存在差异，这要求在迁移前进行详尽的数据兼容性分析，并制定周密的数据转换策略。任何数据丢失或损坏都可能导致业务中断，影响客户体验，甚至造成不可估量的经济损失。
▶︎ 2.3.3 性能与成本权衡
数据库迁移的另一大驱动因素往往是成本效益分析，特别是考虑到Oracle许可费用较高，企业可能会探索开源或云原生数据库解决方案以降低成本。然而，这一转变需要对性能表现进行重新评估。新数据库系统是否能够维持或提升原有业务处理速度，尤其是在高并发场景下，成为衡量迁移成功与否的关键指标。此外，还需考虑长期运维成本、技术支持可用性等因素，确保整体拥有成本（TCO）的最优。
▶︎ 2.3.4 技术生态与未来兼容
随着云计算、微服务架构的普及，新数据库系统的选择还需考虑其在现代技术生态中的适配性，包括对容器化、自动化部署、DevOps流程的支持。同时，面对AI、大数据分析等新兴技术的融合趋势，新数据库应具备良好的扩展性和灵活性，以支撑未来业务的创新与发展。综上所述，客户的系统迁移至新数据库平台，绝非简单的“即插即用”，而是涉及到技术、成本、业务流程多维度的综合考量。通过详尽的前期规划、严谨的技术选型、细致的数据迁移策略及充分的测试验证，才能最大限度地减少业务调整的阵痛，确保平滑过渡，为企业长远发展奠定坚实的基础。这一过程不仅是技术挑战，更是对企业战略眼光与执行能力的一次全面考验。
3. PolarDB的解决方案
面对复杂多变的技术挑战，阿里云瑶池PolarDB PostgreSQL团队与客户运维团队紧密合作，凭借专业知识和坚定的决心共同克服了一系列挑战。
3.1 一主多读架构承载巨量的流量压力
在应对日益增长的客户流量需求时，PolarDB采取了一种高度优化且策略性的一主两读部署架构，这一设计融合了事务处理（Transaction Processing, TP）与分析处理（Analytics Processing, AP）的分离原则，从而实现了资源利用的最大化与服务性能的显著提升。
产品架构 🔗 https://help.aliyun.com/zh/polardb/polardb-for-oracle/architecture-3
▶︎ 3.1.1 主数据库：TP业务的坚实后盾
主数据库作为整个架构的中枢，专精于处理高并发的在线交易事务，如订单处理等即时操作。通过采用先进的锁机制与事务管理策略，它确保了数据的一致性与事务的ACID特性（原子性、一致性、隔离性、持久性），即便在面对尖峰流量时也能维持极低的延迟响应。此外，通过将复杂的分析型查询任务分流至从库，主库得以从长时间运行的查询中解放出来，专注于快速处理短事务，从而有效避免了因慢查询导致的服务瓶颈，确保了前端应用的流畅用户体验。
▶︎ 3.1.2 从数据库：AP负载的高效担当
两个从数据库的配置，为系统的分析处理能力提供了强大的支撑。通过对主库的数据实时复制，从库拥有近乎完整的数据副本，能够独立承担起报表生成、大数据分析、业务趋势预测等分析型工作负载。这种设计不仅充分利用了数据库的读取扩展性，还通过智能调度算法，根据查询类型和资源占用情况自动分发任务，实现了查询效率与资源使用的最优化。
▶︎ 3.1.3 集群负载均衡与系统稳定性增强
通过精细的负载均衡策略，PolarDB的这种部署模式确保了集群内资源的高效分配。每个组件都根据其设计目的进行专门优化，避免了资源争抢，提升了整体服务的吞吐量和响应时间。单一实例的高性能表现，归功于架构设计对硬件资源的高效利用以及软件层面的智能优化，减少了对外部扩展的依赖，降低了运维复杂度与成本。
▶︎ 3.1.4 读写分离的效果
主数据库的流量：下图展示了主数据库每日的在线交易流量情况。在日常业务高峰时段，主数据库需要承受每秒超过2万次的事务提交压力，突显出作为在线交易核心的TP数据库对及时处理能力和高效运作的严格需求。
从数据库的流量：下图展示了从数据库每天的查询流量情况。观察可见，查询分析业务每日的事务提交量平均仅为数十次，但普遍处理速度较慢，这主要归因于大多数事务属于分析报告类型的业务。这映射出AP数据库的一个显著特征，即倾向于执行大规模查询而事务流量相对较低。
3.2 TB级别大表优化，承载高强度IO更新
面对大数据时代下对数据库系统提出的严峻挑战，尤其是在处理超大规模数据表时，PolarDB针对4TB级别大表引发的性能瓶颈，采取了一系列创新性策略，不仅从底层架构上进行了优化，还考虑了实际运行环境下的效率与稳定性问题。以下是对PolarDB所实施优化措施的深入解析与扩展讨论。▶︎ 3.2.1 PolarDB-PG的文件校验流程简化
在传统的数据库管理系统中，确保数据完整性通常要求在每次数据写入前进行繁琐的文件校验过程，这包括定位写入位置、验证文件状态等步骤，尤其是对于拥有数千个分段文件的大表而言，这一过程成为了显著的性能拖累。PolarDB-PG通过智能算法优化，实现了在保障数据完整性的前提下，精简了这一流程，具体体现在：
-
智能预计算与缓存策略：系统在首次访问或定期维护时，预先计算并存储各分段文件的写入位置信息，后续写操作直接利用这些预计算结果，避免了每次写入都需遍历文件的低效行为。
-
动态分段管理：设计了一套高效的分段文件管理系统，能够根据写入压力动态调整分段策略，减少文件碎片化，进一步优化写入路径，从而在源头上降低了频繁文件操作的需求。
▶︎ 3.2.2 表大小缓存机制的引入
数据库的优化器是决定查询执行计划的关键，其准确度直接影响查询性能。传统方式下，优化器在做成本估算时，直接从磁盘读取每个分段文件的大小，对于大表而言，这一操作无疑增加了额外的I/O负担。PolarDB-PG创新性地引入了表大小缓存机制，该机制具有如下优势：
-
即时反馈与高效估算：将表的总大小及其分段信息在内存中缓存，使得优化器在生成执行计划时能快速获取所需信息，无需等待耗时的磁盘I/O操作完成，显著提升了查询规划的效率。
- 自适应更新策略：缓存系统具备智能感知功能，能够根据表的实际更新频率动态调整缓存刷新策略，确保数据的新鲜度与准确性，同时平衡了内存使用与查询效率。
▶︎ 3.2.3 综合性能与系统效率的提升通过上述优化措施，PolarDB不仅有效解决了大表查询与写入的性能瓶颈，还在多个维度上增强了系统的整体表现：
-
增强I/O性能与响应速度：显著减少了因文件句柄操作引发的系统开销，特别是对磁盘的频繁读写操作，直接提升了数据库在高负载情况下的I/O吞吐量与响应时间。
-
优化并发处理与资源管理：有效缓解了高并发环境下文件描述符的限制问题，确保了数据库在处理大量并发请求时的稳定性和效率，减少了系统级错误的发生概率。
- 提升系统资源利用率与稳定性：通过减少不必要的系统调用，优化了操作系统资源分配，降低了CPU占用率，提升了系统整体的稳定性和长期运行的可靠性。
3.3 Oracle迁移全链路解决方案
PolarDB PostgreSQL版与Oracle生态高度兼容，全面拥抱Oracle数据库的基础架构，确保对所有基本数据类型的支持。同时，PolarDB还关注到数据库结构的细节，全面兼容Oracle的4605个内置函数，这其中包括了从日常数据处理到高级分析的各类函数，对于22个DBMS内部包和318个系统视图，也实现了准确的对应和支持，这为用户的数据库运用提供了更多灵活性和便捷性。
了解更多
🔗 https://help.aliyun.com/zh/polardb/polardb-for-oracle/commercialization-announcement-of-polardb-postgresql-compatible-with-oracle-version-2-0
▶︎ 3.3.1 Oracle 深度兼容
其深度兼容还体现在对Oracle特有语法特性的复现上，如ConnectBy用于实现层次化查询，RowNum用于数据分页，以及同义词的灵活运用，这些都使得从Oracle到PolarDB的过渡十分顺畅。此外，PolarDB在支持分区表、事务处理、PL/SQL等核心功能的同时，也充分考虑到企业级应用的需求，提供用户自定义包以促进代码重用，实现复杂逻辑封装，以及异构连接能力，确保多源数据整合的顺畅无阻。更进一步，PolarDB引入了诸如闪回表、全局临时表、全局索引等高级特性，显著提升了数据管理和恢复的效率，而透明数据加密（TDE）则为数据安全加上了一把坚实的锁，确保信息资产的安全。
▶︎ 3.3.2 一键迁移服务
在迁移服务方面，PolarDB提供的去Oracle解决方案是一套高度精细化和全面的策略体系。这一方案涵盖了迁移的几大步骤：1. 迁移前进行详尽评估，精确识别迁移风险与挑战；2. 使用自动化工具辅助结构迁移，确保数据库架构的准确重建；3. 高效执行数据迁移并实时监控；4. 迁移后进行数据校验，确保数据的正确性。尤为值得注意的是，PolarDB还考虑到了数据反向回流的可能需求，为迁移过程增设了一条安全可靠的回退路径，大大增强了迁移方案的灵活性和可靠性。
通过一个直观易用的控制台界面和清晰明了的操作指南，PolarDB简化了原本复杂繁琐的迁移流程，使得像欧派这样的客户能够以最小的业务中断和最少的应用修改成本，顺利完成从Oracle到PolarDB的“心脏置换”。
3.4 并发索引清理，解决大表年龄回收难题
为了深入解决大数据量环境下数据库维护，尤其是大表回收过程中数据库年龄增长过缓这一挑战，我们探索并实施了一项创新策略——并行索引清理技术。这项技术的核心在于通过多线程或分布式处理能力，加速对数据库中无效或已删除记录的空间重用过程，从而提升整体系统性能与响应速度。我们模拟了极端条件下的数据操作场景，具体而言，执行了高达5000万次的事务处理，主要涉及大量的UPDATE操作。这些操作并未采用原地更新策略，而是产生了大量的冗余数据，导致数据库表急剧膨胀。这一过程精确地复现了高并发、高频更新的实际应用场景，为后续的优化措施提供了真实可靠的测试基准。
随后，我们保留了多个数据副本以确保测试的全面性和准确性，并着手利用不同配置的Vacuum作业进程进行数据库清理。Vacuum作为一个关键的维护进程，负责回收已删除或更新记录所占用的空间，对于保持数据库健康状态至关重要。在这一环节，我们特别关注了并行处理能力的影响力，通过调整Vacuum工作者进程的数量，我们发现当启用7个并行工作者进程时，清理效率相较于单进程模式提升了三倍以上。这一显著的性能提升不仅验证了并行处理策略的有效性，也为后续的实践应用奠定了理论基础。一个单一表体积达到4TB的数据回收任务，在未进行优化前，该任务的执行时间预计会超过10小时，这对于追求高效运营的企业而言，无疑是一个不可接受的延迟。针对这一难题，我们引入了并行索引扫描机制，该机制能够同时扫描多个索引分区，大大加快了数据定位与处理的速度。此外，我们还采取了策略性的垃圾回收执行时机选择，即在系统负载相对较低的峰值时段执行Vacuum操作，以最小化对业务运行的影响。
通过上述综合策略的实施，我们成功地将该4TB大表的垃圾回收时间压缩至2小时以内，这不仅有效缓解了表空间膨胀问题，还显著提高了数据库的整体运行效率和资源利用率。
3.5 慢SQL优化
客户的业务中有很多长期存在的慢SQL，这些慢SQL有诸多危害，包括慢SQL会导致应用程序的响应时间变长、长时间运行的查询会占用大量的CPU和内存资源，这可能会影响到其他进程和查询的性能。长时间执行的SQL可能会持有锁定时间过长，导致其他事务等待，产生锁争用，甚至可能导致死锁等。慢SQL查询的存在会减少系统整体效率，增加维护和运营成本，并可能导致用户体验的明显下降。
▶︎ 3.5.1 慢SQL优化1
和用户沟通发现了一例慢SQL，平均执行时间13s，explain analyze发现基数估计不准导致nestloop被执行很多次，最终通过创建扩展统计信息解决了这个问题，最终执行时间控制在1秒以内。
这个SQL从13秒最终加速到1秒，大大提升了应用的响应速度，并节省了服务器的CPU、内存资源。
▶︎ 3.5.2 慢SQL优化2
分析发现，因为nestloop导致这个节点的执行时间为 189.326ms * 1765 = 334149.8 ms 占据了98%的执行时间。进一步观察发现，这一个节点的行数估计值与实际值相差较大，怀疑是统计信息过期，导致代价不准；
执行 set default_statistics_target to 1000;analyze ecc_csc.cc_base_customer ecc_csc.cc_base_project_relation ecc_csc.cc_base_userinfo; 后
SQL执行时间变为 629.975 ms，降低了3个数量级。
3.6 全方位的自动化监控
PolarDB-PG还支持使用全局自动负载信息库（Global Automatic Workload Repository，简称GAWR）对数据库进行全方位多维度的监控。如下图所示，监控指标涵盖CPU、内存、I/O、文件系统、TPS、连接数、缓存命中率、延迟、慢SQL等多个维度，基于这些指标可以对数据库系统问题进行详细分析。
了解更多 🔗 https://help.aliyun.com/zh/polardb/polardb-for-postgresql/overview-65
4. 总结
在欧派客户去Oracle上云的道路上，尽管遇到诸多问题与挑战，但得益于PolarDB不断的自我优化和阿里云先进的云计算能力，核心业务上云得以圆满完成。上云后，欧派不仅享受到了云计算时代所带来的高效算力优势，也通过PolarDB卓越的多读架构和计算能力，实现了部分SQL执行速度比Oracle快3-5倍的效果，并大幅提升了整体业务效率。此外，欧派还成功摆脱了对Oracle体系的依赖，实现了业务的平滑迁移与系统升级，转向了自主创新的PolarDB数据库。欧派客户的监控和日常运维可以依赖PolarDB的最新自动化监控体系（GAWR），并且任何数据库层面的问题都能由阿里云的运维工程师迅速响应和解决。这次上云经历为欧派与阿里云创造了双赢的局面，也为国内家居行业的互联网化数字转型树立了杰出范例。
· END ·
点击了解 PolarDB PostgreSQL版 更多内容
