本文来自微信公众号“twt企业IT社区（talkwithtrend.com）”，【作者】刘华阳，某互联网金融数据库负责人。
PostgreSQL平替Oracle数据库项目中，应用和基础架构运维改造是重要的组成部分。应用改造包含数据库对象转换、SQL查询的修改、应用程序代码更改、性能影响评估与优化、监控与运维的改造等，这些都是项目中需要考虑的。基础架构在项目中要起到助攻的作用，配合应用方面的改造。由于数据库的改变，整体应用和运维架构需要进行评估和规划，还包括高可用（备份、容灾）方案评估与改造、后期的异构数据库的数据迁移工作等。
1.PostgreSQL平替Oracle数据库对于存储设备有哪些要求？
1)容量需求的变化与增长的考虑。根据数据库本身的机理不同，对于存储的容量可能有更高的要求，如表膨胀，WAL日志增量较快，更多的日志归档空间的需求等。
2)读写速度的提升需求。在项目转换中，PostgreSQL数据库为了更高效的处理数据，对存储系统读写速度有更高的要求，尤其需要对集中式存储的性能要进行考量。
3)可靠性和稳定性的要求。针对硬盘坏块或者物理坏块，在硬件上要有进行错误更正和数据冗余的方法。
这对于集中式存储系统提出了一定的要求，如存储系统是否有更先进的硬件设计，能够支持更大容量存储扩展的需求；是否采用了混合闪存、硬盘驱动器等多种存储介质；是否具备灵活扩展的能力，能满足数据库在存储扩展中的线性扩展要求。在性能方面，存储中是否有高速的处理器和全互联交换网络（如25G、100G RDM网卡）、提供更高数据的传输效率；是否通过高速的缓存系统降低数据读取的延迟；是否采用冷温热多层数据管理的策略，避免出现物理坏块的情况；以及读写均衡策略叠加大比例EC以避免物理坏块带来的影响等等，都需要在项目进行中进行考量，这也是项目中基础运维改造需要进行分析和改善的部分。
2.PostgreSQL平替Oracle数据库中应用改造需要考虑哪些角度？
需要分析使用Oracle数据库的软件项目的特征有哪些，了解应用改造的需求，并从源头对项目进行更深入的了解和分析：
2.1软件开发角度
基于Oracle数据库的软件开发项目有以下部分特点：
1)以基于Oracle为中心的数据库开发为主导思想的项目，与Oracle数据库绑定比较深入，如部分程序的实现是通过存储过程来进行实现的，或由于早期的软件项目中网络部分并不发达，考虑网络带宽方面，软件项目的主要程序都避免进行大量的交互，而是将程序集中通过存储过程组织，通过应用程序调用数据库中的存储过程来实现，减少数据传输。
2)在基于Oracle的应用程序中，表设计和SQL语句的形成多使用传统的三范式设计模式，数据的访问和提取等都设计多个表的关联查询，甚至有部分应用程序的数据准确性都是通过数据库来完成的，如CHECK输入数据库表的字段值是否符合要求，通过约束来保证整体应用的数据输入的正确性或范围性。
3)单表的数据量在基于Oracle的项目中，可能有较大数量的情况，同时也有的表已经做了分区表等方式，并且需要进行多个硬件存储分担数据存储和性能的平衡等，使单体数据库能完成数据处理的日常工作。
2.2运行维护角度
1)Oracle数据库在国内的运行维护环境是较好的，大部分公司雇佣的Oracle数据库管理员都有相关的培训认证，同时由于Oracle曾经在国内流行，相关的知识体系也比较完整。
2)Oracle数据库本身自有的数据库性能分析功能、第三方分析软件，以及相关功能脚本都比较完善，有着一整套成熟的工作模式和分析方式。
3)Oracle运行维护的人员素质较高，在招聘市场上，高中低端的人才都有充足的储备。
4)在大型项目中，Oracle数据库基本上统一建立在集中式的存储中，如SAN存储，通过SAN存储方式可以快速的进行高可扩展性和可靠性。通过先进的SAN存储来提供更快速的数据库响应速度。
2.3成本角度
1)使用Oracle的软件项目主要考虑的是数据库本身的版权费用，以及每年可能偿付的维保费用。
2)安装使用数据库的硬件费用和灾备容灾的费用，以及匹配的一些商用的Oracle备份的软件费用，如果还有异地灾备，那么相关的费用会更高。
因此，初期基于DBA转型的培训费用和商用的PostgreSQL运行维护的软件费用，或专业的PostgreSQL外包维护的费用都应该被考虑进维护成本中。
小结：实际上从软件开发角度和成本角度来看，PostgreSQL在支持存储过程函数，以及与Oracle相同的数据表存储方式上，在前期都是较好的Oracle平替数据库的选型方案，但项目的分析和评估的工作仍然是应该进行的。
3.企业在对核心应用系统进行数据库更换前应做什么样的准备？
在数据库平替选型的工作前，需要确认在这项工作中的难点是什么，企业是否可以在这样的平替项目中获得更大的利益或者减少成本付出。
- 除了在技术上的付出和研究以外，最重要的一点是企业的一把手对该项目的理解和支持，在不少IT项目中，高层管理者并不理解相关的工作的意义，并且对于项目本身的难度也不了解，这样在项目中后期会遇到推进较慢的情况。
- 有足够的成本预算针对中大型应用系统更换核心数据库过程中可能付出的成本，并有这样的预期。
- 有针对新数据库特性有一定了解的研发团队和有针对新数据库的运维维护有一定经验的DBA或相关人员。
总体来说，一个核心应用项目更换数据库本身就要做好相关的人员准备、资金准备、相关的时间成本付出的准备，以及企业业务决策与技术决策部门的合作。
4.适合Oracle to PostgreSQL平替项目的应用程序有什么特点？
对这些特点了解越多，平替项目成功的概率就会越高：
- 应用程序有明晰的应用程序的开发的说明，尤其针对Oracle中存在的存储过程的说明，函数说明；
- 应用程序中无深度使用Oracle独有的功能的部分，如Oracle中的自主事务处理、物化视图等；
- 应用程序中基本没有使用嵌入式的Oracle PLSQL语句，或使用Oracle特定的OCI或JDBC类型；
- 应用程序在数据库表中的数据量适中（10TB），而不是数据量超巨大；
- 应用程序服务的业务有固定的停机时间，或进行切换的情况下可以进行停机切换。
5.数据库平替项目中的工作只是DBA的工作吗？
在基于Oracle的平替项目中，尤其针对以PostgreSQL作为数据库承接的对象，经常听到这样一种误区，即Oracle to PostgreSQL的数据库平替项目中的工作只是DBA的工作，或仅仅局限于数据库的数据迁移。不少项目的管理者，在进行这项工作时的思维很有可能受到这个思维定式的局限，认为平替与其他部分无关。实际上，Oracle to PostgreSQL的平替项目需要各方面的支持和前期工作。
整体的项目工作流程设计、项目难点的前期调研等，都需要进行多方的论证和考量。其中主要需要思考平替项目的本身的成本预估，项目后期的运维的难点和成本，以及整体的工作时间成本，是否存在技术难以突破的点，这些都是前期的分析中要摆到桌面上的问题，需要进行分析和讨论后，再进行实施。项目成功与否，重点在于前期的重视和准备程度，以及业务部门的支持和理解等。
6.平替项目中需要深度了解PostgreSQL的数据库原理吗？
这实际上是一个容易被忽视的问题，PostgreSQL和Oracle不是一个数据库原理设计的理念，尤其PostgreSQL相对于Oracle、MySQL在MVCC多版本控制中的差异，让开发者在使用PostgreSQL过程中的开发注意事项与Oracle大相径庭。同时也需要观察项目的大小以及业务的重要性，判断在前期是否需要有深入理解PostgreSQL数据库原理的开发人员和运行维护人员加入，尽量事前避开可能的问题点。比如，如果PostgreSQL对于存储的速度有更高的需求，或如果原有的存储系统使用了DAS存储或NAS存储，则在此次数据库切换项目中，需要考虑替换存储系统，使用更先进的SAN存储，为迁移在硬件性能上提供更多的保证。
图1：DAS存储NAS存储SAN存储
7.平替项目中的开发人员在项目成败中的重要性
在Oracle to PostgreSQL的平替项目中必然存在修改应用程序代码的问题，同时可能涉及业务逻辑轻度或深度修改的问题，如原有的Oracle的功能不能在PostgreSQL中实现，需要通过修改程序代码来完成和填补其中的“亏空”，同时如果将压力全部积压到PostgreSQL数据库本身，完全通过数据库自身的功能完全覆盖Oracle的特殊功能范畴，将有很大的难度和产生后期运行故障的概率，在部分切换项目中，如程序为购买，并且已经脱保，这样的项目失败的可能性较大，而公司自主开发的，或有软件的维保商，并支持二次开发的，这样的项目成功的概率较大。
8.运行维护是平替项目的中的关键
前期需要设计数据库高可用架构匹配适合的硬件配置如SAN存储系统，后期需设计匹配PostgreSQL数据库的运行维护监控的系统，包括监控指标、操作流程与SOP文档和常规操作命令等诸多问题。运行维护是项目上线后3-6个月成败的关键，如备份的方式转变，数据恢复方式的改变等，在遇到基于PostgreSQL核心技术的转变后的技术问题、性能问题，以及快速发现问题和解决问题等都是运行维护需要关注和进行相关工作的部分。
结语
Oracle to PostgreSQL的数据库平替项目，并没有想象中的那么难，对于相关项目需要注意的部分可以总结为以下几点：
1）项目前期要重视，与相关部门达成一致；
2）项目前期提前规划存储系统替换、扩容或升级；
3）项目前期需调研，PostgreSQL运行原理要弄懂；
4）项目前期需要规划整体架构；
5）项目前期列出项目中无法进行平替的功能点，通过其他的方式来解决；
6）项目前期运行维护需投入，避免项目上线再解决；
7）项目上线前应做POC，发现性能问题及时解决和改造；
8）项目后期持续观察发现问题，运维能力需跟上。
