从PostgreSql看数据库的发展

2019-04-10 15:36:33

业界一致有一位“大神”，每天都在传播POSTGRESQL 的知识，一直倡导POSTGRESQL 是可以替换ORACLE的开源数据库。从目前的掌握的知识看，部分企业和部分环境中，PostgreSql 是可以替换的。

试想如果使用微服的结构，可能有些设计还是没有办法脱离存储过程，选择MYSQL 来承接这样的事情是一件头疼的事情，使用PG来承接是一个好的方法。如果说MYSQL 是一个要求高的大家闺秀，PG 可以理解为一个不挑食的灰姑娘。

同时业界MYSQL 和 PG 互怼的事情天天发生，个人不这么看，这两种数据库应该是一对好弟兄，MYSQL 主打OLTP，多种的复制方式，变化多端的架构设计，设计好了读写分离，可以适应多种场景，这是收费的和 PG 都不擅长的。

反过来，必须要存储过程，外键，或者OLAP+OLTP 混合的场景，对单库的功能需求，性能要求，以及一些变态的需求，基本上PG 是能不动声色的完成的。

以需求来决定使用数据库的类型的时代，已经到来了，在我近的一段工作中工作可以分为三个部分

1 对各种数据库的功能点，长处，坑，未来发展的知晓，至少你不会听到一个满是存储过程的项目，并且固化多年，要进行数据库系统的更换，脑子抽风的去建议用MYSQL。

2 对业务的熟悉的程度，如果对业务不熟悉，你怎么通过某些业务的特殊性来使用对应的某种数据库的长处，将这些特殊性化解。

3 针对各种数据库的SQL 语句，来优化相关的性能

而目前随着多种数据库的使用，未来会爆发的问题也是显而易见，数据融合困难，数据分析的困难，如果你只有一种数据库，和你有几种数据库，来将数据进行分析，无论从数据的量级和难易程度都不是一个LEVEL。

所以一个问题的解决很可能带来另一个问题的产生，或者多个问题的产生，嗅觉灵敏的话，可以提前获知某些问题的产生，并提前研究或学习。

另外还有一个问题，就是数据库的维护问题，大企业可能雇人做运维平台，小企业可能大部分还停留在手工的阶段，同时较少可能购买较贵的某种单项的数据库运维平台，因为那是在是不划算的一件事情。

所以我比较担心，单独某种数据库的商业化的平台的前景如何，另外云数据平台自带的运维和监控的工具也能满足大部分小企业的需求。

而相反，数据库的种类繁多，造成的就是能维护的人员的匮乏，而如何布局提供服务，并且更专业的服务倒是一门好生意（有公司正在做）。而市场上对能操作多种数据库的人员的需求也会暴增，一个数据库吃一辈子的事情不会再存在，这样的需求已经在北京，上海这样的大城市的大公司产生。是广而全，还是小而美，我不知道那个更好，但脚踩几只船，可能站的更稳。

说了这么多，还没有提到题目的主角 POSTGRESQL，这里就说说POSTGRESQL 的 extension。

这也是POSTGRESQL 对比其他数据库的一个特色，或者算一个优点。

PostgreSQL 的扩展在 contrib 模块，这里称为 extensions，大致扩展的组成由以下几个方面

1 扩展的sql 文件

2 扩展控制文件

3 扩展的库文件

如何来判断是否已经开启了 extensions，我们直接在LINUX 命令下，执行 pgbench -V 来查看，如果有，说明安装的时候是支持的。

另外要知道的是，pg的扩展是针对数据库的，并不是和MYSQL 一样，将PLUG-IN 安装后，所有的数据库都被支持。 PG 只是针对你一个数据库，并不是整体的 instance,(请尝试用SQL SERVER 在一台计算机上安装多个INSTANCE ,你只在一个INSTANCE 上做了设置，所以你不能奢求其他的INSTANCE 有你没有做设置的功能)。

另一个好处就是， extensions 在新版本的PG，上是可以运行老版本的extension。

还有一个问题就是扩展的时候，这个概念就类似 LINUX 的概念，一个扩展可能会依赖其他的扩展，通过CASCADE 来将没有安装的其他依赖包一次安装。

而通过扩展的方式，PG 又有一个新的与其他数据库进行数据交互的方式，例如：PG 想读取 CSV的数据表，我们普通的方式是做DBLINK的方式，而PG的想法是我是不是能直接去读取通过进行 file_fdw的方式，跳过了 DBLINK，直接将一个文件作为自己的数据文件来读取。

我们来做一个实验，我们先建立一个文本文件，名字叫data_pg