从Oracle迁移到PostgreSQL的10个原因

注：本文翻译自https://severalnines.com/blog/top-ten-reasons-migrate-oracle-postgresql/

Oracle关系数据库管理系统(RDBMS)已被大型组织广泛使用，被认为是迄今为止市场上最先进的数据库技术。通常将RDBMS与作为产品应该提供的标准“事实”的其他数据库产品进行比较。它被db- enginees.com评为当今市场上可用的头号RDBMS。

PostgreSQL被列为排名第四的RDBMS，但这并不意味着迁移到PostgreSQL没有任何优势。PostgreSQL自1989年以来一直存在，1996年开源。PostgreSQL在2017年和2018年连续两年获得年度最佳数据库管理系统奖。这表明吸引大量用户和大型组织的势头丝毫没有减弱。

PostgreSQL吸引大量关注的原因之一是，人们正在寻找一种替代Oracle的方法，这样他们就可以减少组织的高成本，并摆脱供应商的锁定。

从一个可工作且高效的Oracle数据库迁移可能是一项艰巨的任务。对公司TCO(总拥有成本)等问题的担忧是企业迟迟不决定是否放弃甲骨文的原因之一。

在这篇博客中，我们将看看为什么很多公司选择离开Oracle而迁移到PostgreSQL的一些主要原因。

原因一：PG是真正的开源产品

PostgreSQL是开源的，并在PostgreSQL许可证下发布，这是一个自由的开源许可证，类似于BSD或MIT许可证。获得产品和支持不需要任何费用。

如果您想利用数据库软件，这意味着您可以免费获得PostgreSQL数据库的所有可用特性。PostgreSQL在数据库领域已经成熟了30多年，自1996年以来一直是开源的。几十年来，开发人员一直致力于创建各种扩展功能。这本身就使得开发人员、机构和组织选择PostgreSQL作为企业应用;为领先的业务和移动应用程序提供支持。

组织再次意识到，像Postgres这样的开源数据库解决方案提供了更大的容量、灵活性和支持，而不完全依赖于任何一家公司或开发人员。与之前的Linux一样，Postgres一直是由专门的用户设计的，这些用户选择将他们的解决方案返回给社区来解决日常业务问题。像Oracle这样的大型开发人员可能有不同的动机来开发有利可图的产品，或者支持一个狭窄但有利可图的市场，而Postgres社区则致力于为日常关系数据库用户开发最好的工具。

PostgreSQL通常在不增加太多复杂性的情况下执行这些任务。它的设计严格侧重于处理数据库，而不必浪费资源，比如通过添加的功能来管理额外的IT环境。这是开源软件的用户从Oracle迁移到PostgreSQL时喜欢做的事情之一。花费数小时研究Oracle数据库如何工作的复杂技术，或者如何优化和调优，最终可能会得到昂贵的支持。这诱使机构或组织寻找一种替代方案，可以减少成本，带来利润和生产力。请查看我们之前的博客，了解PostgreSQL如何将SQL语法与Oracle语法相匹配。

原因二：不需要License并且拥有强大的社区

对于Oracle RDBMS平台的用户来说，很难找到任何免费或不收取高额费用的社区支持。机构、组织和开发人员经常在网上找到可以免费提供问题答案或解决方案的替代信息。

当使用Oracle时，很难决定是否使用特定的产品，或者是否使用产品支持，因为(通常)涉及大量资金。你可能会尝试一个特定的产品来测试它，最后买了它，只是意识到它不能帮助你。使用PostgreSQL，社区是免费的，并且充满了经验丰富的专家，他们很乐意帮助您解决当前的问题。

您可以在https://lists.postgresql.org/上订阅邮件列表，开始与社区联系。PostgreSQL的新手或天才可以在这里交流、展示和分享他们的解决方案、技术、错误、新发现，甚至分享他们的新兴软件。你甚至可以通过irc.freenode.net和加入#postgresql频道来寻求IRC聊天的帮助。你也可以通过加入https://postgres-slack.herokuapp.com/或https://postgresteam.slack.com/来联系Slack社区。有很多选项可供选择，也有很多开源组织可以为您提供问题。

如果你想在PostgreSQL中查看专业服务，有很多选项可供选择。即使查看他们的网站https://www.postgresql.org/support/professional_support/northamerica/，你也可以在那里找到一大批公司，其中一些价格很便宜。即使在这里，我们也提供对Postgres的支持，这是ClusterControl许可证或DBA咨询公司的一部分。

原因三：广泛的SQL一致性支持

PostgreSQL一直热衷于适应并遵从SQL作为其语言的事实上的标准。SQL标准的正式名称是ISO/IEC 9075“数据库语言SQL”。标准发布的任何后续修订版本都会取代之前的版本，因此声称与早期版本一致没有官方价值。

与Oracle不同的是，一些关键字或操作符仍然不符合ansi标准的SQL(结构化查询语言)。例如，OUTER JOIN(+)操作符可以将与其他没有接触或最不熟悉Oracle的DBA之间的混淆归因于此。PostgreSQL遵循ANSI-SQL标准的JOIN语法，这使得它可以轻松和简单地与其他开源RDBMS数据库(如MySQL/Percona/MariaDB数据库)进行跳转。

另一种在Oracle中非常常见的语法是使用分层查询。Oracle使用非标准的START WITH…CONNECT BY语法，而在SQL:1999中，分层查询是通过递归的公共表表达式实现的。例如，下面的查询根据分层查询而改变其语法:
Oracle

SELECT

    restaurant_name, 

    city_name 

FROM

    restaurants rs 

START WITH rs.city_name = 'TOKYO'

CONNECT BY PRIOR rs.restaurant_name = rs.city_name;

PostgreSQL

WITH RECURSIVE tmp AS (SELECT restaurant_name, city_name

                                 FROM restaurants

                                WHERE city_name = 'TOKYO'

                                UNION

                               SELECT m.restaurant_name, m.city_name

                                 FROM restaurants m

                                 JOIN tmp ON tmp.restaurant_name = m.city_name)

                  SELECT restaurant_name, city_name FROM tmp;

PostgreSQL的方法与其他顶级开源RDBMS(如MySQL/MariaDB)非常相似。

根据PostgreSQL手册，PostgreSQL开发的目标是与最新的官方版本的标准保持一致，这样的一致性不会与传统特性或常识相矛盾。它支持SQL标准所需的许多特性，尽管有时语法或函数略有不同。事实上，这就是PostgreSQL的优点，因为它也得到了不同组织的支持和合作，无论大小。其美妙之处在于它的SQL语言与标准的一致性。

PostgreSQL的开发目标是与最新的官方版本的标准保持一致，这样的一致性不会与传统特性或常识相矛盾。它支持SQL标准所需的许多特性，尽管有时语法或函数略有不同。随着时间的推移，可以预期进一步的一致性。

原因四：查询并行化

公平地说，与Oracle的SQL语句并行执行相比，PostgreSQL的查询并行性并不丰富。Oracle的并行特性包括语句排队提示、设置并行度(DOP)的能力、设置并行度策略或自适应并行性。

PostgreSQL基于支持的计划有一个简单的并行度，但这并不意味着Oracle优于开源的PostgreSQL。

PostgreSQL的并行性一直在不断改进，并不断得到社区的增强。当PostgreSQL 10发布时，它增加了更多对公众的吸引力，特别是对合并连接、位图堆扫描、索引扫描和仅索引扫描、聚集合并等并行性支持的改进。改进还向pg_stat_activity添加了统计信息。

在PostgreSQL版本< 10中，并行性默认是禁用的，你需要设置变量max_parallel_workers_per_gather。

postgres=# timing

Timing is on.

postgres=# explain analyze select * from imdb.movies where birthyear >= 1980 and birthyear <=2005;

                                                   QUERY PLAN                                                   

----------------------------------------------------------------------------------------------------------------

 Seq Scan on movies  (cost=0.00..215677.28 rows=41630 width=68) (actual time=0.013..522.520 rows=84473 loops=1)

   Filter: ((birthyear >= 1980) AND (birthyear <= 2005))

   Rows Removed by Filter: 8241546

 Planning time: 0.039 ms

 Execution time: 525.195 ms

(5 rows)



Time: 525.582 ms

postgres=# o /dev/null 

postgres=#  select * from imdb.movies where birthyear >= 1980 and birthyear <=2005;

Time: 596.947 ms

查询计划显示，实际执行时间约为522.5 ms，而实际查询执行时间约为596.95 ms。在实现并行性的同时，

postgres=# set max_parallel_workers_per_gather=2;

Time: 0.247 ms

postgres=# explain analyze select * from imdb.movies where birthyear >= 1980 and birthyear <=2005;

                                                          QUERY PLAN                                                           

-------------------------------------------------------------------------------------------------------------------------------

 Gather  (cost=1000.00..147987.62 rows=41630 width=68) (actual time=0.172..339.258 rows=84473 loops=1)

   Workers Planned: 2

   Workers Launched: 2

   ->  Parallel Seq Scan on movies  (cost=0.00..142824.62 rows=17346 width=68) (actual time=0.029..264.980 rows=28158 loops=3)

         Filter: ((birthyear >= 1980) AND (birthyear <= 2005))

         Rows Removed by Filter: 2747182

 Planning time: 0.096 ms

 Execution time: 342.735 ms

(8 rows)



Time: 343.142 ms

postgres=# o /dev/null

postgres=#  select * from imdb.movies where birthyear >= 1980 and birthyear <=2005;

Time: 346.020 ms

查询计划确定查询需要使用并行性，然后它确实使用Gather节点。在执行2次工作时，实际时间估计为339ms，在查询计划汇总之前估计为264ms。现在，查询的实际执行时间为346ms，这与查询计划估计的实际时间非常接近。

这正好说明了使用PostgreSQL是多么快速和有益。虽然PostgreSQL有自己的限制，当并行可以发生或者当查询计划确定它比使用并行更快时，它并没有使它的特性与Oracle有很大的不同。PostgreSQL的并行性是灵活的，只要你的查询匹配查询并行性所需的序列，就可以正确地启用或使用。

原因五：高级的JSON支持并且不断改进

与其他开源RDBMS相比，PostgreSQL对JSON的支持总是不相上下。看看这篇来自LiveJournal的外部博客，其中PostgreSQL对JSON的支持表明，与其他RDBMS相比，PostgreSQL总是更先进。PostgreSQL提供了大量的JSON函数和特性。

JSON数据类型是在PostgreSQL-9.2中引入的。从那时起，它有了很多重要的增强，其中最主要的是在PostgreSQL-9.4中增加了JSONB数据类型。PostgreSQL提供了两种存储JSON数据的数据类型:JSON和jsonb。jsonb是JSON数据类型的高级版本，它以二进制格式存储JSON数据。这是一个主要的增强，对PostgreSQL中JSON数据的搜索和处理方式产生了很大的影响。

Oracle对JSON也有广泛的支持。相比之下，PostgreSQL具有广泛的支持和函数，可用于数据检索，数据格式化或影响数据输出甚至存储在数据库中的数据的条件操作。使用jsonb数据类型存储的数据具有更大的优势，可以使用GIN(广义倒排索引)来有效地搜索大量jsonb文档中出现的键或键/值对。

PostgreSQL有额外的扩展，可以帮助实现jsonb类型到其支持的过程语言的TRANSFORM FOR TYPE。这些扩展是PL/Perl的jsonb_plperl和jsonb_plperlu。而对于PL/Python，它们是jsonb_plpythonu, jsonb_plpython2u和jsonb_plpython3u。例如，使用jsonb值来映射Perl数组，您可以使用jsonb_plperl或jsonb_plperlu扩展。

ArangoDB发布了一个基准测试，比较了PostgreSQL和其他支持JSON的数据库的JSON性能。虽然这是一个老的博客，但它仍然展示了PostgreSQL的JSON与其他数据库相比是如何执行的，其中JSON是其数据库内核的核心特性。这使得PostgreSQL有自己的优势，即使是附带的特性。

原因六：主要云供应商对DBaaS的支持

PostgreSQL作为DBaaS得到了广泛的支持。这些服务分别来自亚马逊、微软的Azure数据库和谷歌的Cloud SQL。

相比之下，Oracle只能在Amazon RDS上用于Oracle。主要参与者提供的服务以可承受的价格开始，并且非常灵活地根据您的需求进行设置。这有助于机构和组织进行相应的设置，并减轻其在Oracle平台上捆绑的大量成本。

原因七：更好地处理海量数据

PostgreSQL RDBMS不是为处理分析和数据仓库工作负载而设计的。PostgreSQL是一个面向行的数据库，但是它有存储大量数据的能力。PostgreSQL在处理数据存储方面有以下限制:

限制	值
最大数据库容量	无限制
最大表容量	32TB
最大行大小	1.6TB
最大字段大小	1GB
单表最大行数	无限制
单表最多字段数	250-1600，基于列类型而定
单表最多索引数	无限制

PostgreSQL的主要好处是，它有一些插件可以用来处理大量的数据。TimeScaleDB和CitusData的cstore_fdw是可以用于时间序列数据库的插件之一，可以存储来自移动应用程序的大数据，或者来自物联网应用程序的数据，或者数据分析或数据仓库。实际上，ClusterControl提供了对TimeScaleDB的支持，这使得部署变得简单而容易。
如果你想使用PostgreSQL的核心特性，你可以使用jsonb存储大量的数据。例如，大量的文档(PDF、Word、Spreadsheets)使用jsonb数据类型存储。对于地理定位应用程序和系统，可以使用PostGIS。

原因八：扩展性，高可用性，冗余/地理冗余，以及廉价的容错解决方案

Oracle提供了类似但功能强大的解决方案，如Oracle Grid、Oracle Real Application Clusters (RAC)、Oracle Clusterware和Oracle Data Guard等等。这些技术可能会增加您不断增加的成本，并且部署和稳定的成本是不可预测的。要抛弃这些解决方案很难。必须加强培训和技能，并培养参与部署和实施过程的人员。

PostgreSQL有大量的支持，有很多选项可供选择。PostgreSQL将流和逻辑复制内置到软件的核心包中。你也可以为PostgreSQL设置一个同步复制，以获得更高的可用性集群，同时让一个备用节点处理你的读查询。对于高可用性，我们建议您阅读我们的博客PostgreSQL的Top PG集群高可用性(HA)解决方案，其中涵盖了许多很棒的工具和技术可供选择。

还有一些企业特性提供高可用性、监视和备份解决方案。ClusterControl就是这种技术之一，与Oracle解决方案相比，它的价格实惠。

原因九：支持多种过程语言:PL/pgSQL、PL/Tcl、PL/Perl和PL/Python

从9.4版本开始，PostgreSQL有了一个很棒的特性，你可以根据自己的选择定义一个新的过程语言。虽然并不是所有的编程语言都被支持，但是它有许多被支持的语言。目前，在基本发行版中，它包括PL/pgSQL、PL/Tcl、PL/Perl和PL/Python。外部语言有:

名称	语言	网址
PL/Java	Java	https://tada.github.io/pljava/
PL/Lua	Lua	https://github.com/pllua/pllua
PL/R	R	https://github.com/postgres-plr/plr
PL/sh	Unix shell	https://github.com/petere/plsh
PL/v8	JavaScript	https://github.com/plv8/plv8

这样做的好处是，与Oracle不同，刚开始使用PostgreSQL的开发人员可以快速地为他们的应用系统提供业务逻辑，而无需再花时间学习PL/SQL。PostgreSQL为开发人员创造了一个更简单、更高效的环境。PostgreSQL的这种特性是开发者喜欢PostgreSQL并开始从企业平台解决方案转向开源环境的原因之一。

原因十：大型文本数据的灵活索引(GIN, GiST, SP-GiST和BRIN)

在索引支持方面，PostgreSQL有一个巨大的优势，它有利于处理大数据。Oracle有很多索引类型，对于处理大型数据集也很有用，尤其是全文索引。但是对于PostgreSQL，这些类型的索引是根据您的目的而灵活的。例如，这些类型的索引适用于大数据:

GIN -(广义逆指数)
这种类型的索引适用于jsonb、hstore、range和array数据类型列。当您的数据类型在单列中包含多个值时，它非常有用。根据PostgreSQL文档，“GIN被设计用来处理这样的情况:被索引的项是复合值，索引处理的查询需要搜索出现在复合项中的元素值。例如，项目可以是文档，查询可以是搜索包含特定单词的文档。”

GiST -(广义搜索树)
由节点页组成的高度平衡的搜索树。节点由索引行组成。叶节点的每一行(叶行)通常包含一些谓词(布尔表达式)和对表行(TID)的引用。如果您将GiST索引用于几何数据类型，例如，您希望查看两个多边形是否包含某个点，则GiST索引是最好的。在一种情况下，一个特定的点可能包含在一个框中，而另一个点只存在于一个多边形中。在处理全文搜索时，希望利用GiST索引的最常见数据类型是几何类型和文本

在选择使用哪种索引类型(GiST还是GIN)时，请考虑以下性能差异:

• GIN索引查找大约比GiST快三倍
• GIN索引的构建时间大约是GiST的三倍
• GIN索引的更新速度比GiST索引稍慢，但如果禁用了快速更新支持，则速度会慢10倍左右
• GIN索引比GiST索引大两到三倍

根据经验，GIN索引最适合静态数据，因为查找速度更快。对于动态数据，GiST索引的更新速度更快。

SP-GiST -(空间分区GiST)
对于具有自然但不均匀聚类的大型数据集。这种类型的索引利用空间分区树。SP-GiST索引在数据具有自然聚类元素且不是均衡树的情况下最有用。一个很好的例子是电话号码，例如在美国，他们使用以下格式:

• 区号是3位数字
• 3位数字作为前缀(历史上与电话运营商的交换机相关)
• 行号为4位

这意味着你在第一组3位数周围有一些自然聚类，在第二组3位数周围有一些自然聚类，然后数字可能以更均匀的分布呈扇形分布。但是，对于电话号码，一些区号的饱和度要比其他区号高得多。结果可能是树非常不平衡。由于预先的自然聚类和数据的不均匀分布——比如电话号码——可以成为SP-GiST的一个很好的案例。

BRIN -块范围指数
对于按顺序排列的大型数据集。块范围是一组彼此相邻的页面，其中关于所有这些页面的摘要信息存储在Index中。块范围索引可以专注于一些与SP-GiST类似的用例，因为当数据有一些自然的排序，并且数据往往非常大时，它们是最好的。拥有十亿记录表，特别是时间序列数据?BRIN也许能帮上忙。如果您查询的是自然分组在一起的大数据集，例如几个邮政编码的数据(然后汇集到某个城市)，BRIN可以帮助确保磁盘上相似的邮政编码彼此靠近。

当您有非常大的数据集，如日期或邮政编码排序时，BRIN索引允许您非常快速地跳过或排除大量不必要的数据。此外，相对于整体数据大小，BRIN被维护为较小的索引，这使得当您拥有大型数据集时，它们是一个巨大的胜利。

结论

在与Oracle的企业平台和业务解决方案竞争时，PostgreSQL有一些主要优势。很容易将PostgreSQL作为开源RDBMS的首选，因为它几乎与Oracle一样强大。

甲骨文很难被击败(这是一个难以接受的事实)，要抛弃这家科技巨头的企业平台也不容易。当系统为您提供强大的功能和高效的结果时，这可能是一个两难的选择。

有时候，你不得不做出决定，因为在平台成本上的持续过度投资可能会超过其他业务层和优先级的成本，这可能会影响进展。

PostgreSQL及其底层平台解决方案可以帮助你降低成本，缓解你的预算问题;都有中等到小的变化。