PostgreSQL技术问答00 - Why Postgres

笔者关于Nodejs的还有很多的坑还没有填上，这里又打算开一个新的坑系列-PostgreSQL，因为它们都是在Web应用开发中常用的技术。这里也不是写书，写博客就可以更随意一点。内容的碎片化不可避免，但只能先这样。可能等到时机成熟的时候，再重新组织整理一下。

这个系列的主题是：《PostgreSQL使用问答》，主要是总结针对在开发中遇到的一些PostgreSQL技术方面的疑问和思考，并且结合实例来进行分析和解答，在这个过程中，既解决了技术方面的问题，也提升了开发者的认知和水平。

本文作为系列文章的开篇，我们将会讨论一些和PostgreSQL数据库系统的背景相关的问题。笔者认为，这是除了技术本身之外，涉及到一个软件系统的价值观和方法论的基本问题，其实对于我们理解它是比较重要的。

什么是PostgreSQL

PostgreSQL的官方网站(下图)是： www.postgresql.org

网站上已经对于PostgreSQL这个软件系统，说得很清楚明白了。

PostgreSQL:

The World's Most Advanced Open Source Relational Database

这句话里面，有三个要点：

• 关系数据库系统

主要指关系数据模型和SQL语言的支持。说明PG是一个什么类型的软件和系统。

• 开源软件

PG确实是开源软件。但笔者认为，PG的强大，更在于它拥有一个成熟稳定的开源技术社区，能够保证其作为开源软件系统的长期平稳发展，这其实比软件开源本身还重要。

• 最先进

如果考虑的是开源关系数据库系统，它确实也名副其实。这主要体现在其强大而稳定的性能，对SQL完善的支持，丰富的特性，可扩展性等等。从这些角度来看，它也一点都不逊色于像Oracle、MS SQL Server这类主流的商业软件。

再说说这个产品名称是怎么来的。笔者在另一篇文章里面也提到过，PostgersSQL其实是三个单词(Post-gres-SQL)构成的：

• gres: Ingres的简化(后详)
• Post: 后Ingres的意思，意为这个软件发展来自Ingres
• SQL: 使用SQL技术和语言的关系型数据库系统

简单而言，PostgerSQL的意思就是“支持SQL的后ingres数据库系统”。这其实简单的体现了这个产品的一个发展历史和过程。

Ingres的全称是Iteractive Graphics REtrieval System(交互式图形检索系统) 是始于1970年代早期加州大学伯克利分校的一个研究项目，在这个项目的研究基础上产生了关系型数据模型的理论和软件雏形；Postgres是其在80年代的后继项目，增加了类型定义和完整描述数据关系的能力；实际上Postgres计划在1993年已经终止；但是在1994年，有人在其BSD许可的基础上，利用其原始代码进行了后续开发，主要是加入SQL语言解释器，让它更像是一个标准的SQL数据库软件，命名为Postgres95，并在1996年重新命名为PostgreSQL，并作为开源软件系统，基于互联网进行分发，初始分发的版本就是PostgreSQL 6.0，可以视为PostgreSQL软件的正式开端。

为什么要选择PostgreSQL

单纯的讨论这个问题，或者和其他软件进行技术细节方面的比较，其实也没有太大的意义。因为实际上，任何一个软件，只要有人使用，就可能有它的独特价值和应用场景。没有软件天生就好或者烂，好的软件都是逐渐发展和完善起来的，关键是这个改善的过程能否平稳持续，并且能够与时俱进。

当然，选择PG肯定也是有一些理由的，笔者这里想从借用一张Hasso Plattner Institut制作的关系型数据库家谱开始：

从这个家谱，我们应该可以感觉到，在所有的关系数据库系统分分合合，纵横交错，新旧变换的历程来看，PostgreSQL的发展一直是比较顺利稳定的。同时，作为开源软件系统，它也非常重视开源社区的建设和管理，这些都奠定了它在技术发展上，具有一定稳定性、适应性和前瞻性。

笔者感觉，和其他系统相比，PostgerSQL在技术上是经典的开源和互联网软件开发体系，这些特点和优势在于：

• 专注于互联网应用开发的支持，和传统关系数据库系统专注于企业应用开发构成差异化
• 发展策略是小幅改进、快速迭代、重视生态，贴近和适应互联网应用开发技术的发展
• 理论先行，作为学院派软件，PG具有前瞻性的系统架构，严谨规范的架构设计，合理的软件和特性的生命周期管理
• 功能丰富，易于扩展，这些都是快速多变的互联网应用开发所需要的，例如对于多种数据类型、数组、JSON等的支持，pgcrypto、uuid扩展等等
• 跨平台支持，由于开源和基于C语言开发的属性，PostgreSQL很早就规划了对于多个主流操作系统平台的支持
• 标准的关系型数据库特性：关系数据模型、高效的存储和索引引擎、ACID、SQL语言、网络服务等等
• SQL标准规范的积极支持，并扩展出很多强大和实用的使用方式，如CTE、Returning、filter等等
• 软件系统的稳定性，虽然没有数据方面的支撑，但从笔者的使用体验还有社区口碑而言，这个系统是非常稳定和可靠的，而且对于运维的要求，并没有想象那么高，还是非常易用和健壮的

这里额外提供一个有趣的信息，PostgreSQL的产品logo(下图)，就是一头大象。可能开发者认为大象可以很好的代表PosgreSQL的产品特性和形象，就是强大、稳健和可靠。

Postgres有什么比较优势

这个问题，可以看成上一个问题的扩展和细化。这里说明一下，这里的总结和认知，主要是来源于笔者开发和使用的一些有限的经验和感受，可能有一些主观偏颇的认知和刻板影响，甚至可能有错误的地方，仅作为参考。

• vs Oracle

和Oracle相比，笔者需要先承认，作为商业数据库的老大，Oracle确实是在系统的容量、稳定性、商业解决方案的完善性方面占有优势。但相对而言，Oracle的功能复杂、对系统软硬件环境和运维能力的要求很高，再加上昂贵的授权和服务费用，都给用户带来了很高的负担。特别是对于很多互联网类型的Web应用而言，很多特性和功能都是没有必要的。而且，作为商业软件系统，它过于强调系统的稳定性，在技术发展和灵活性方面，其实是满足不了现代互联网应用技术的快速发展的。

因此，和Oracle相比，PG的主要优势软件容易使用，功能丰富，扩展性好，技术发展速度快，互联网应用技术的适应性和灵活性更好，开发、部署、使用和维护成本低。

具体到技术细节，比如Array和JSON的支持，pgcrypto扩展，位操作符，CTE、数据修改返回、关联更新和删除等的特性，笔者觉得起码都比Oracle实现的更加直观优雅。当然，笔者也有很长时间都没有用过Oracle了，但基于国内Oracle部署大部分还是10G或者12C的情况来看，应该没有太大的改观。

• vs MySQL

MySQL本身就是为支撑互联网应用而开发设计的轻量化开源软件产品。基于市场定位和快速投入市场的考虑，MySQL在架构设计和实现细节方面，特别是早期版本，其实是有一些缺陷的。比如MyISAM文件系统的可靠性、UTF编码、实体化视图、窗口函数功能薄弱的问题等等，都造成了一些负面影响。

后来Oracle收购了MySQL，新发布的版本，在功能和性能上确实有了长足的进步，基本补足完善了作为一个企业级系统应该具备的性能和特性。但又带来了一个结构性的问题就是“Oracle的诅咒”。在Oracle的体系内，MySQL的处境非常尴尬，对于它的健康发展带来了一些影响。

在技术方面，笔者基本上没有在MySQL易主和升级之后，使用过它的新的版本，听说评价还是不错的，所以不能基于旧有的使用经验进行评价。只能说，在主观感受而言，PostgreSQL的功能更加丰富，这点和Oracle对比的情况相类似，而且对于更大规模数据处理的时候，性能相对要好一点，也更稳定，这可能得益于其更长时间的开发和应用过程，以及更好的系统架构设计和实现。

• vs MS SQL

大家都知道，MSSQL是微软重要的企业级软件产品。它的优势就是和微软的开发工具集成的非常好，基本上可以无缝对接管理和使用。但MSSQL的主要问题就是它不能跨平台部署，这在现在Linux占有大半壁江山的互联网技术体系内，本身就是一个巨大的问题。

但其实微软也在进步，从2017年开始，SQL Server已经能够部署在有限的几个Linux发行版本之上，甚至还支持容器化部署。从技术上分析，作为主要作为服务器系统的数据库软件，只要拥有全部完整的原始代码和设计，模块化和依赖管理做得好得话，在Windows和Linux之间进行移植，对于这种大厂，并不是一个很困难的事情，主要的考虑是商业方面的。

在技术方面，笔者也很久没有接触过SQL Server系统了。最早接触这个系统的时候，还是微软刚从Sybase手中收购此技术不久，差不多是6.5和7.0的版本，所以是不能作为评价依据的。只能说，印象中，SQL Server的SQL语法特别是存储过程的语法是比较奇怪的，在开发工具中的使用，也有很浓重的微软的风格，其他关于性能、稳定性、功能方面，当时没有相关的技术和意识，无法予以评价。

• vs SQLite

谁是这个信息技术宇宙中装机量最为庞大的关系型数据库系统？ 可能很多行业人士都不曾想到过这个问题，答案是： SQLite。 因为它基本上会作为一个嵌入式数据库系统，被集成到很多系统和软件当中。比如小型的网站、手机APP、应用软件(如浏览器)数据存储、嵌入式设备和系统等很多场景，其实都是适合SQLite来支撑和使用的。

当然直接对比SQLite和PostgreSQL是不合适的，它们的特性和适用场景截然不同。这里的讨论其实就是为了明确这一点。SQLite的最大优势就是相对完整的支持SQL语言，但很轻量。现实中，很多本地运行的场景，是需要对结构化数据进行管理的，比如一些中间的业务数据、配置信息、字典数据等等，但这些数据通常也不会太大，也没有竞争操作的问题，但需要进行一些数据操作时，SQL又是比较适合和方便的，这一，SQLite就是特别适合的技术和选择。

和PG这种全功能的数据库系统相比，SQLite的主要缺陷是缺乏网络库和完善的事务管理，存储和性能的优化也不是重点考虑的方向，当然，这些应当算是其产品定位做出的权衡和选择，而非系统设计缺陷和不足。

• vs MongoDB

MongoDB是文档型NoSQL数据库系统的代表，所谓文档型，就是它存储的是BSON(类似JSON)文档。其数据模型是面向文档的，自包含结构的数据，没有固定的模式。文档型数据库技术，是随着互联网应用开发的发展而发展起来的，因为开发者认识到，很多互联网应用的方式和数据结构，并不是特别适合于关系型数据库。比如很多动态结构的数据，它们可能更适合于使用键值和对象结构存取，关系型数据库的优势很难体现。由此，在一些应用场景下，使用MongoDB也取得了很好的效果，包括开发速度和灵活性，在后续的发展中，文档数据库的性能和数据完整性支持也不断优化，在应用层面上，已经可以和关系型数据库相提并论了。

基于这个趋势，Postgres也在不断发展，增加了一些文档数据库的特性和操作方式，比如对于JSON的支持，hstore数据结构等等，让PG在某种意义上，也能够作为一个文档数据库来使用。

当然，这两个产品，严格来说不是同一个类型的产品，其实应该是无法直接对比的。这里的对比，主要是考虑到PostgerSQL可以作为对象或者键值数据库使用。首先是作为文档数据库，PG的实现还是和MongoDB是有差异的，需要对代码进行相关的调整和适配，比如编写一个适配程序，将文档操作转换称为关系数据操作。另外在性能和优化上，关系型数据库并没有像文档数据库那样方便处理。所以，笔者认为，Posgres，可能只适合于在特定的场景中，如对文档数据操作的简单支持，来进行使用，而不能直接将其当作文档数据库的主要业务和技术基础。

Postgres有什么缺点或者不足

从技术和宏观上来看，几乎没有。因为关系型数据库系统技术发展到现在，已经是非常成熟和稳定的了。市场上存活下来这么几家，基本上可用性都非常好，不会有什么无法被接受的功能缺失或者缺点，有一些差异，几乎完全取义于对于场景和适应程度，开发体系的匹配以及开发者喜好。

但如果要较真的话，这里也可以尝试例举几条：

• XID

XID就是TranactionID(事务ID)，PG使用XID来对事务进行标识和管理。但PG设计的XID是一个32位的无符号整数。它有容量限制(2^32，40亿）。如果数据库的修改操作过于频繁或者数据过于庞大，可能会溢出并导致数据错乱的情况。这时需要运维人员进行关注和维护。

• 数据表分区

老版本的PG，没有提供完善的数据表分区方案，需要一些额外的设置和操作。但这一问题已经在最近几个版本的迭代中基本上得到了解决，现在的数据表分区，功能和易用性已经基本和Oracle无异。

• 类型转换

一些MySQL的使用者，在进行数据库系统迁移的时候，觉得PostgreSQL的数据类型限制是比较强的，很多地方不能像MySQL一样进行自动的类型转换，显得不够"智能"。笔者在日常使用过程中，确实也经常遇到和类型处理相关的问题，比如很多方法调用，都需要明确的参数类型，稍有不注意就会报错。当然解决一般也比较简单，就是加入类型转换或者强制声明就可以了。确实需要适应一下。

本质上而言，类型转换策略是一种技术选择和平衡，作为C语言编写的程序，可能PostgreSQL对此有所继承，认为类型限制是程序正确执行和优化的一个重要条件，所以要求比较严格。

• 群集和高可用

这一点可能相比Oracle略微逊色。PostgreSQL没有原生的群集和高可用性技术，但它也提供了基于日志的数据复制机制。一些社区和第三方开发者在此基础上开发了扩展的高可用集群系统方案。

• 技术资源

笔者觉得，Postgres的社区是做得非常好的。但可能有人会认为它作为开源软件体系，没法提供和商业软件同一级别的服务。还有，特别是在中国，PG的应用还没有像欧美那样广泛，相关的技术、人才的资源相对还是缺乏的。

小结

本文作为PostgreSQL技术问答的开篇，简单的讨论了PostgreSQL的发展背景，和作为技术和产品的特点，让读者在正式进入系列之前，对这个技术有一个相对客观合理的理解和认知。